Application security review · OWASP assessment
We test whether customers can read another account's invoices or change their own permissions. This example follows the findings through development and retesting.
The screenshots use fictional findings and evidence to demonstrate our review process. They do not describe a client engagement.
How the review works
You get access to a custom app where you can follow the review as we build it. You can see the checks and findings as we add them, ask questions, and track fixes with your team.
When the review is complete, you receive a final PDF report. It records what we reviewed, the findings and retest results, and any issues that still need work.
What the review covers
| Review area | What we do |
|---|---|
| Application architecture | The application map shows how the frontend and supporting services handle customer data, where sensitive information is stored, and who can access it. |
| OWASP requirements | Each tested requirement has a result and supporting evidence. This example uses selected ASVS 5.0.0 requirements for authorization and session management. |
| API testing | API tests try to bypass permissions or change protected fields. They also cover sign-in, input validation, and limits on repeated requests. |
| Source code review | Manual code review covers sensitive operations such as permission checks and database queries, along with file handling, secrets, and integrations. Dependency checks look for libraries with known vulnerabilities. |
| Infrastructure and configuration | Depending on the scope, we check HTTPS, security headers, CORS, and deployment settings. We review access to supporting services and the checks that run before a release. |
| Fixing vulnerabilities | Each finding has supporting evidence, a priority, and a recommended fix. We link it to the relevant requirement so the development team knows what to change and how to test it. Higher risks come first. |
| Checks in development | We can add dependency, code, and secret scanning to the build pipeline. Regression tests check that later changes do not reintroduce the flaws we fixed. |
| Review records | The team gets a record of what we tested and what remains open. Closed findings include the fix and retest evidence, so someone returning to the review can see why we closed them. |
Checking the fixes
The findings view shows the fix alongside its retest evidence and review history. It keeps the original severity visible after we close the issue.
Let’s make it secure.
Building something new, introducing AI, or concerned about the security of an existing system? Tell us a little about what you’d like to protect.