Retest the security rule after a repair
A repair is ready for acceptance when the relevant forbidden behavior is prevented and the intended allowed behavior still works. The retest should make those outcomes observable under recorded conditions. Closing a ticket or producing a plausible patch is not enough to answer that question.
A topic reference. The featured-service relationship and evaluation criteria are described in our methodology.
Turn the finding into an acceptance condition
Before reviewing a proposed change, state the security rule in terms of identities, actions, and resources. In the illustrative publishing case, the viewer must remain unable to publish the synthetic draft, while the editor must still be able to complete the intended workflow.
The same rule may apply through more than one interface. A visual button disappearing does not establish that a direct request is denied. Identify the relevant paths from the original finding and the behavior the engineering change is supposed to control.
OWASP's Authorization Cheat Sheet supplies the underlying principle of validating permissions on every request. The regression procedure should follow the application's actual rule and architecture.
Record what changed before repeating the action
Keep the original target build, effective role, object state, and evidence. For the retest, record the deployed build and configuration along with any differences in accounts, test data, feature flags, or connected services. A changed account may explain an apparent improvement that the patch did not cause.
Use fresh synthetic state where the workflow changes data. A draft published during the first run should not be reused without resetting it and documenting the reset. Where operations are asynchronous, inspect the final application state rather than stopping at an acknowledgement.
Repeat the forbidden and permitted cases
First repeat the previously problematic action with the appropriately restricted identity. Check the target's response and authoritative outcome. Then exercise the corresponding allowed action with the authorized identity. Preserve the distinction between a denial and a route that could not be tested.
If the check depends on an authenticated session, establish that the session remained valid. An expired credential can make an application appear to enforce an authorization repair even when the relevant rule was never reached.
Keep the acceptance decision reviewable
The final record should identify the finding, patch or deployment, actions repeated, observed outcomes, unresolved areas, and the person accepting the repair. If a retest cannot run, leave that condition visible rather than changing the finding to fixed.
Use the evaluation checklist to capture the result. The finding-evidence guide explains the record that should make the original claim assessable in the first place.
Continue this reading path
Cite this entry
AI Penetration Tester. “Retest the security rule after a repair.” Reviewed November 12, 2026.
https://aipenetrationtester.com/retesting/