Turn a security finding into acceptance tests
Write regression tests that prove the intended control works. Cover denied access, legitimate use, and side effects without preserving sensitive evidence.
A remediation acceptance test describes the security property the repair must preserve. It should not merely replay one suspicious string or one object identifier. Capture the actor, resource, action, expected decision, and relevant side effects so the engineering team can keep checking the boundary after the review ends.
Use synthetic data and run the tests in an environment the team controls. The OWASP authorization guidance recommends testing authorization logic. The example below is our suggested acceptance record for a fictional tenant-access defect.
What does a useful test matrix look like?
| Given | When | Then |
|---|---|---|
| Member of tenant A | Reads an allowed record in A | Required fields are returned |
| Member of tenant A | Requests a private record in B | Access is denied without exposing the record |
| Removed member of A | Repeats the read | Current membership policy is enforced |
| Member without export permission | Starts an export | No export job or file is created |
| Authorized exporter | Downloads their completed export | Download succeeds under the intended policy |
Choose the response semantics your application requires. A test should verify the intended denial and absence of leaked data rather than assuming one universal status code.
How do you avoid a brittle regression?
Assert the business rule at the appropriate layer. A UI test that confirms a button is hidden does not establish server-side enforcement. A mocked policy call may establish that a handler invokes the policy, but not that the policy correctly resolves membership.
Use a combination appropriate to the risk: focused policy tests, integration tests with real ownership records, and a small number of workflow checks. Keep the boundary clear so a passing mock does not get reported as a deployed end-to-end proof.
Include side effects where the original defect created them. Check queues, records, and file permissions after a denied operation. Do not let a response assertion hide an unauthorized change that already occurred.
What belongs in the engineering handoff?
Record the fixture setup, expected policy, test location, and build or commit that introduced the repair. Link the test to a redacted finding identifier, not to a private evidence dump.
Ask a reviewer to explain what could make the test pass while the defect remained. That question often reveals stale fixtures, overly broad mocks, or missing alternate entry points.
Acceptance tests reduce regression risk. They do not replace a scoped retest of the deployed repair. Discuss remediation support with Sourced when your team needs to turn a finding into a clear, maintainable control.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.
Sources
- OWASP Authorization Cheat SheetAccessed
- OWASP Secure Code Review Cheat SheetAccessed