Scope
We agree on systems, test accounts, timing, and boundaries. Testing starts with authorization.


I test web apps and APIs for access-control flaws. You get evidence, clear priorities, and practical guidance to fix them, with retesting as agreed.
Discuss my projectFor teams building SaaS, APIs, and Shopify apps.
Does your app enforce them?
A login screen does not answer the most important question: once someone gets in, what can they actually do?
I test login, account recovery, sessions, and permissions. The focus is whether an ordinary user can act as an administrator or reach someone else’s data.
I check what your API accepts when a request changes: another ID, another role, another customer. Your interface can hide a button. Your API has to block the action.
I examine store isolation, authentication flows, and app endpoints. One store should never be able to read or change another store’s data.
I review paths that may have been overlooked during development: data access, privileged actions, storage, and exposed endpoints. AI-generated code gets the same scrutiny.
You get the steps to reproduce it, the business impact, and what needs to change in the code. Every finding has to stand up to scrutiny.
Authorization reviewIllustrative example · fictional data
/api/projects/project_bThe server must verify resource ownership on every request.
Before the fixWe agree on systems, test accounts, timing, and boundaries. Testing starts with authorization.
I work through real workflows, combining manual analysis with tools for repetitive coverage.
Confirmed findings, evidence, and recommendations go into a report your team can put to work.
Agreed retesting checks the fixes within scope and records anything that still needs attention.
I’m Junio Silva, founder of Rust Cybersecurity. I work on web application and API security, with a particular focus on who can access or change each piece of data.
I’m based in the United States and work in English and Portuguese. You speak directly with me about the scope, findings, and next steps.
Finding the flaw is the start. The next step is fixing it.Junio Silva
Yes. I only test systems you own or are authorized to have assessed. Scope and boundaries are agreed before any testing begins.
Testing is planned to reduce impact. I prefer a test environment where possible, agree on limits with you, and avoid destructive tests. No security test is entirely risk-free.
Cost and timing depend on functionality, access roles, integrations, and system size. After reviewing your project, I send a proposal with scope, price, and timeline.
I use test accounts and data wherever possible, collect only what is necessary, and agree on evidence handling. Client findings are never published without permission.
No. An assessment covers an agreed scope at a point in time. It helps find and fix vulnerabilities, but cannot guarantee that none remain.
Tell me what you are building and what you need to protect. The first conversation helps us decide whether an assessment is right for your project.
Please do not send passwords, API keys, or customer data.