04 /Security Assessment
OWASP Security Assessment
A methodical review of one web application and the API behind it, worked through against the OWASP references by a person rather than by a schedule of scans. You receive issues that were reproduced, severity reasoning you are free to argue with, and a fix order driven by what genuinely threatens the business rather than by category name.
What you get
Rules of engagement agreed in writing
Targets, credentials, test windows, the accounts we may create and the actions that stay off limits, all settled before the first request is sent. Ambiguity here is how a test turns into an incident call at ten at night.
A finding record with evidence attached
Each issue carries the request that triggered it, the response that proved it, and a capture where the effect is visual. Nothing enters the document on the strength of a tool’s confidence rating alone.
Severity rated against your product
We weigh impact inside your application rather than against a generic scale, and we write down the reasoning. The identical technical flaw can be trivial in an internal admin screen and existential in a consumer wallet.
A fix order driven by consequence
Remediation sequenced so the first week of engineering effort removes the most exposure, with guidance written for the stack you actually run. A list sorted alphabetically by vulnerability class is a list nobody starts.
Verification of the fixes and a reissued document
Once your changes are deployed we confirm each one and republish, with the closed items marked and dated. A procurement reviewer wants the version where the issues are resolved, not the version where they were discovered.
How it runs
- 01
Scope and rules of engagement
We settle what is in scope, which environment the work runs against, which roles we need accounts for, and what happens if something serious surfaces mid-engagement. It goes into a document before anything is touched.
You provide: Environment access, accounts at every privilege level, and a named contact for the test window
- 02
Map the application
Before any attack surface is probed we walk the product to learn what it is for: which data belongs to whom, which actions move money or record consent, and where the trust boundaries genuinely sit rather than where the architecture diagram places them.
We produce: An attack-surface map · A matrix of roles and the operations each may reach
- 03
Work the methodology
Systematic coverage of the OWASP categories, with tooling sweeping the mechanical checks and human effort spent where tooling cannot go: access control between two accounts, and sequences of individually legal requests that add up to something harmful.
We produce: Reproduced findings with evidence · Working notes on what was covered and what was not
- 04
Report, walk through, verify
The report reaches you with a summary for the people who sign things and reproduction detail behind it, then we sit with your developers while they work through the changes. Verification follows once those changes are live.
We produce: Assessment report · Remediation working session · Retest report
Where this stops
- Not a certified penetration test. We are not an accredited testing body and we hold no notified-body status, so where a contract, an insurer or a certification scheme names a formal pentest with attestation attached, this does not satisfy it and we will say so before you commit.
- Not a compliance certificate. Findings can serve as evidence while you answer a security questionnaire or prepare for an audit, but the document itself certifies nothing and no engineer can sign one on your behalf.
- Not a network, infrastructure or physical-security exercise. The boundary is the application and the API serving it. Firewall policy, VPN configuration, staff laptops and building access all sit outside the scope.
- Not permanent. The report describes the code that was deployed during the test window, and a feature shipped the month afterwards is untested by it.
Related reading
- Application security
OWASP assessment vs penetration test: which one your requirement names
Suppliers use the two terms interchangeably. Contracts, insurers and regulators do not. How to read the clause you have been given before you buy the wrong thing.
- Application security
Broken object level authorisation: the API risk no scanner will find for you
The top entry on the OWASP API Security Top 10 returns a perfectly normal 200 to the wrong person. Why tooling cannot see it, and how the testing actually runs.
- Application security
Triaging dependency vulnerabilities: what to do with 400 open alerts
A scanner dashboard nobody opens is worse than no scanner. How to sort advisories by whether they can actually be triggered, and how to record the ones you defer.
FAQ
OWASP Security Assessment questions we hear often
How long does an assessment take?
For one web application with an API behind it, plan on two to three weeks from access being granted to the report landing, with most of that spent testing rather than writing. The variables that actually move the number are how many distinct user roles exist and how much business logic sits behind authentication. We would rather scope narrowly and test properly than spread a fortnight across four products.
Can you test against production?
A staging environment that mirrors production is the better place for this, because a handful of checks are destructive by nature and a shared database makes them expensive. Where no such environment exists, we will work against production inside limits and a window you set. What we will not do is begin against a live system without having had that conversation first.
Do you need our source code?
No, and most of this work runs without it. Testing from outside with valid accounts sits closer to the position an attacker occupies, which keeps the findings honest. Source access helps in two places: confirming a suspected issue without a hundred probing requests, and pointing at the exact place to change. Share a repository and we will use it. If you cannot, the work still happens.
What if you find nothing serious?
Then the report says so, and that is a legitimate result rather than a refund conversation. In practice it is uncommon. Access control between accounts is where issues nearly always surface, because it has to be re-checked on every single endpoint and it is the control automated tooling handles worst. A clean report that lists its coverage is still a document your customers can read.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.