Your Security Fix Still Has to Let People In

The person responsible for the product's access policy decides, before the repair agent changes it. Authorization means deciding whether a particular identity may perform an action on a resource. Authentication establishes who that identity is. A successful login doesn't settle which documents it may read or which records it may change.

Write the expected decisions in an authorization matrix: a table connecting identities, actions and resources to allowed or denied outcomes. Include ownership and organization boundaries where they matter. OWASP's authorization testing guidance describes using such a matrix to drive integration tests. That's a concrete input an agent can work from.

Gunner Technology's position is that the repair agent mustn't quietly rewrite that table to make its patch pass. If the policy is unclear, stop and ask the policy owner. Removing legitimate access is a product decision with consequences, even when the change arrives inside a security fix.

Run the same forbidden request against the affected version and the proposed repair, with its starting permissions held constant. First establish that the request crosses the boundary it shouldn't. Then establish that the patched version prevents that crossing. Preserve the setup, identities, resource ownership and observed outcomes so another verifier can repeat the comparison.

Use synthetic records in an isolated test environment. An owner should be able to read their own protected document; another ordinary account shouldn't. After the repair, repeat both requests. If neither account can read anything because the service won't start or the test records disappeared, the run hasn't demonstrated a working authorization rule.

This follows the verification route in Free Security Scans Still Need a Triage Budget. The narrower requirement here is to keep the permitted operation beside the forbidden one throughout the repair. Otherwise an agent can satisfy the rejection check while accidentally removing the behavior you were trying to protect.

Test the relevant neighboring permissions, including another account with the same role and an account with a different role. OWASP's Web Security Testing Guide distinguishes horizontal bypasses, which cross between identities, from vertical bypasses, which reach privileges the caller doesn't hold. Fixing one doesn't establish that the other is closed.

For each protected operation, ask whether the caller owns the resource, shares an approved relationship with it or has explicit permission to act on it. Include anonymous callers where the feature's policy distinguishes them. Where an application separates organizations, verify that a role inside one organization doesn't grant access inside another.

Keep the test identities separate and confirm which identity each request actually uses. A helper that silently supplies an administrator session can make an ordinary user's check meaningless. Let the factory create the fixtures and run the combinations, but keep the expected decisions tied to the approved policy rather than inferred from whatever the implementation currently returns.

No. Check the protected result as well as the response: denied reads mustn't return protected content, and denied writes mustn't make the forbidden change. An error can arrive after an action has already happened. A test that looks only at the response can miss that consequence.

Exercise the server request directly as well as the visible interface. Hiding a button doesn't prove that its operation rejects an unauthorized caller. OWASP's authorization recommendations call for checking permissions on every request and enforcing controls outside client-side code. Test the actual enforcement point your application relies on.

Check permitted results just as carefully. A successful response with an empty document isn't proof that the owner can still read it. Compare the returned synthetic content or resulting state with the approved expectation. Keep diagnostics useful without putting credentials or protected records into routine test logs.

A separate verifier should establish the evidence, and the authorized person should judge whether the returned work is right. The builder can propose tests and repair code. It shouldn't be able to erase a failing permission case, change its expected outcome or grant itself an exception to the release requirements.

Keep the approved matrix, test fixtures, results and exact code revision together. Our post Your Approval Belongs to a Version explains why later edits can invalidate earlier evidence. Apply that rule here: if a repair changes a shared access check, rerun the permission cases that depend on it before presenting the candidate for release.

Start with a protected operation in a repository you own. Make the factory demonstrate forbidden access before the fix, correct rejection afterward and continued success for permitted work. Preserve those checks for later changes. The security repair earns its place when the boundary holds and the product still does the job people are allowed to do.