Canonical: https://dokima.net/insights/what-to-check-after-a-security-fix/ Updated: 2026-11-04T23:30:51+00:00 [← All insights](https://dokima.net/insights/) Checking a security fix # You've fixed a security issue. What should you check next? Three practical questions to ask before closing a security issue: does the original problem stop, are other routes protected, and can the right people still use the feature? Engineering Leadership27 October 20265 minute read ## Key takeaways * Start with the original problem and confirm that the fixed version blocks it. * Check other ways of reaching the same information, such as downloads and mobile apps. * Keep a repeatable test and a short record of what the team checked. Your team has fixed a security issue. The change has been reviewed, the tests pass and a release is ready. What should you ask before marking the issue done? You need a clear account of what went wrong, how the fix addresses it and what the team checked. Three questions make that conversation easier: 1. Does the original problem now stop? 2. Could someone reach the same information another way? 3. Can the right people still use the feature normally? Consider a fictional invoicing application. A customer reports that changing the invoice number in a link lets them view another customer’s invoice. The team adds a check to the invoice page so customers can only open invoices belonging to their own company. That is a useful starting point. Here is how to follow it through. ## 1\. Does the original problem now stop? Ask the team to repeat the reported steps against the fixed version, using test accounts and fictional invoices in an environment they control. In our example, a customer from Company A tries to open an invoice belonging to Company B. The application should refuse access and return no private invoice details. An error message that still includes the other company’s name, address or invoice amount would leave part of the problem unresolved. The team should be able to explain the rule in one sentence: **a customer can only read invoices belonging to their company, subject to their account’s permissions.** That rule gives everyone something concrete to check. Ask which version was tested, too. The check should cover the change you intend to release. Once it is deployed, confirm that the intended version is running, with any further checks agreed by the team and carried out safely. ## 2\. Can the same invoice be reached another way? An invoice may be available on a web page, through a PDF download and in a mobile app. Each route needs to enforce the same access rule. Suppose the web page now refuses access, but its PDF download uses a separate part of the application that still accepts any invoice number. The visible page is fixed while the download remains exposed. Ask the engineer owning the fix to identify the related routes and check how each decides who can use it. This includes code that was unchanged by the patch. A shared permission check can help keep the rule consistent, and the team should confirm that the relevant routes actually use it. This is the practical reason to [look beyond the changed lines](https://dokima.net/insights/pull-request-security-checks-vs-full-codebase-review/): the information being protected can be reached through several parts of the software. ## 3\. Can the right customer still use it normally? Check both sides of the rule. Company A must be unable to read Company B’s invoice, and its authorised staff must still be able to open and download their own invoices. Where customers have different account roles, include those differences. A billing administrator might be allowed to download invoices while another colleague has no billing access. Simply being signed in should not grant everyone the same permissions. This check helps the team catch a fix that blocks legitimate work or grants access too broadly. It also makes the expected behaviour clear to whoever maintains the feature next. ## Keep a check that catches the problem if it returns Ask the team to add an automated test that repeats the important checks whenever the software changes. Engineers often call this a regression test: it catches an old problem coming back. For the invoice example, the test can confirm that an authorised customer opens their own invoice, another company’s customer is refused and the PDF download applies the same rule. The engineer should choose the cases that match the product’s actual permissions. Keep a brief note with the issue as well. Record the version tested, the routes checked, the result and who reviewed it. If a related route still needs work, give it a named owner and an explicit decision rather than letting it disappear when the original ticket closes. For engineers who want more detail, OWASP’s [authorisation guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization%5FCheat%5FSheet.html) explains checking permissions on each request. Its [authorisation testing guide](https://cheatsheetseries.owasp.org/cheatsheets/Authorization%5FTesting%5FAutomation%5FCheat%5FSheet.html) describes organising repeatable tests around features, roles and data. ## A short checklist before closing the issue Use these questions in the handover or release discussion: * **Original example:** Have we repeated it against the fixed version and confirmed that private information stays protected? * **Related routes:** Have we checked other ways to reach the same information, including downloads or mobile access where relevant? * **Normal use:** Can authorised people still do their work, with the intended account permissions? * **Future changes:** Is there a repeatable test that will catch the problem if it returns? * **Record and ownership:** Have we recorded what was checked and assigned any remaining work? ## How Dokima supports the wider investigation [Dokima](https://dokima.net/product/) builds and retains context about your codebase, runs focused security investigations and checks candidate findings before reporting them. That wider context helps engineers examine how related parts of an application handle the same information and permissions as the code changes. For a team investigating an invoice-access issue, the useful questions extend beyond the page that first revealed it: where else is invoice data read, which permission checks protect those routes, and do their assumptions agree? Dokima’s structured review supports that investigation alongside the team’s tests and release checks. Explore the [sample report](https://dokima.net/sample-report/) to see how Dokima presents findings and supporting reasoning, or read about [building a continuing security-review routine](https://dokima.net/insights/continuous-security-review-for-small-engineering-teams/). Next step ## Evaluate this workflow on your own codebase. Dokima runs locally on Linux and macOS using Claude, Codex or OpenCode, with staged architecture mapping, adversarial challenge, deterministic deduplication and developer-ready HTML reports. The 21-day free trial starts on first activation and requires no payment card. [Start 21-day free trial](https://dokima.net/account/?view=register)[View sample report](https://dokima.net/sample-report/)[Browse all insights →](https://dokima.net/insights/) Review the wider codebase ## Find and investigate security issues with Dokima. See how Dokima builds codebase context, investigates potential issues and checks findings. Explore the sample report or start a 21-day free trial. [Start free trial](https://dokima.net/account/?view=register)[Buy Dokima](https://dokima.net/buy/)[View sample report →](https://dokima.net/sample-report/)