Automated scanners find these flaws poorly, because they do not know your rules. Broken access control and business logic bugs are found by tests that encode who may do what, manual review of sensitive paths, role-based testing with real accounts, and human penetration testers. Scanners support those methods but cannot replace them.
Why scanners struggle here
A scanner can tell that a field accepts a quote character. It cannot tell that user A should not read user B's invoice, or that a discount code should apply once. Those rules live in your head and your product spec, not in the code patterns a tool recognises.
OWASP's source code analysis page says it lists authentication problems, access control issues and insecure use of cryptography among the types of vulnerability that are difficult to find by automated searches in source. Dynamic scanners face the same gap from outside, since a request that returns data looks fine unless the scanner knows it should have been refused.
Methods that work
| Method | How it finds the bug | Effort |
|---|---|---|
| Written authorization tests | Automated tests assert who can call what, per role | Medium, then cheap forever |
| Role-swap testing | Replay one user's request with another user's session | Low per endpoint |
| Manual review | A person reads the code around sensitive actions | High, targeted |
| Threat modelling | Lists abuse cases before code exists | Low to medium |
| Independent penetration test | Skilled testers chain logic steps | High, periodic |
A practical approach
- List sensitive actions: view another record, change a price, approve a payment, export data, reset a password.
- Write a role matrix. For each action, record which roles may perform it.
- Turn the matrix into tests. For each cell marked no, assert the request is refused.
- Test identifiers. Change an ID in a URL or body to one the session does not own.
- Test sequences. Skip a step, repeat a step, replay a token.
- Review failures by hand, then add each real bug as a permanent regression test.
Where scanners still help
They catch the plumbing around logic bugs: missing authentication on an endpoint, verbose errors, exposed admin routes. Use them as a safety net while your own tests cover the rules.
Keep the tests close to the code
Authorization tests rot if they live in a separate project. Keep them in the same repository and run them on every pull request. When a feature adds a role or an action, the matrix and tests change in the same change.
Where Safeguard fits
Safeguard does not test application logic or access control. It addresses a separate risk, known flaws in your dependencies, through SBOM and dependency scanning with reachability analysis and gates. Use the free scan at https://gold.safeguard.sh/scan for that part, and keep authorization tests in your own suite.
Quick check
Can a scanner find IDOR bugs?
Rarely. It needs to know which records a session may see. Role-swap tests and written authorization tests are more reliable.
How often should we run authorization tests?
On every pull request. They are fast, and access rules break easily when features change.
Sources
Last reviewed: 19 October 2026.
