Web application penetration testing
Your web app,
tested by hand.
Scanners are good at reflected XSS and stale libraries. They are useless against the flaws that actually get companies breached: broken authorization, abusable business logic, and chains that only make sense if you understand what the application is for.
The bugs that matter are the ones only a human finds.
Broken access control has been the number one web risk for years, and it is precisely the category automation handles worst. A tool does not know that order 40219 belongs to another tenant. It does not know that skipping step three of your checkout gets the goods for free. We test the application you actually built.
Every layer,
every role.
We test each class by hand, from every user role you have, including the ones you forgot were still enabled.
01 · Authorization
Broken access control and IDOR
Every object, every identifier and every role tested horizontally and vertically. Tenant isolation, forced browsing, and privilege boundaries that only exist in the UI. Read the field guide.
02 · Logic
Business logic abuse
The flaws unique to your product. Negative quantities, replayed requests, skipped workflow steps, race conditions on balance changes, and coupon logic that was never meant to stack. Read the field guide.
03 · Injection
Injection across every input
SQL, NoSQL, command, template and XSS, tested on every parameter, header and file name, including the paths your framework claims to sanitise for you.
04 · Identity
Authentication and sessions
Password reset flows, multi factor bypass, session fixation, token lifetime, cookie scope, and the account recovery path that quietly skips MFA entirely.
05 · Server side
SSRF and file handling
Server side request forgery into cloud metadata, upload handlers that trust content type, path traversal in export functions, and XXE where XML is still parsed.
06 · Exposure
Configuration and disclosure
Verbose errors, exposed debug routes, unauthenticated admin panels, source maps in production, and secrets committed to the front end bundle.
Seen in the field
What it looks like
in practice.
An illustrative example of the class of issue this engagement is built to find, and what changes after it.
Illustrative example, not client data
BeforeWhat we found
# signed in as user A, asking for user B's order GET /api/v2/orders/40219 HTTP/2 Cookie: session=<user A> 200 OK { "order_id": 40219, "customer": "user B", "email": "userb@example.com", "address": "..." }
AfterAfter the fix
# same request, ownership now checked server side GET /api/v2/orders/40219 HTTP/2 Cookie: session=<user A> 403 Forbidden { "error": "not_authorised" }
Broken access control. The endpoint checked that you were logged in, never that the record was yours. Every order in the database was readable by changing one number. The fix moves the ownership check into the data layer so it cannot be forgotten per endpoint.
How we test
an application.
A test is only as good as the access you give it. Grey box, with real credentials for every role, finds several times what black box does in the same week.
01
Map the application
Every route, parameter, role and state transition, walked manually with a proxy. We build a model of what the app is supposed to do before trying to break it.
02
Break the boundaries
Each role attempts what it should not be allowed to do. Cross tenant reads, privilege escalation, and direct object references, tested exhaustively rather than sampled.
03
Chain the findings
A medium plus a medium is often a critical. We combine issues into a working path to real data, because that is what an attacker does.
04
Prove and report
Every finding reproduced with the exact request and response, then written up so an engineer can fix it without asking us what we meant.
Brief us on the application.
Request a quoteWhat we need
from you.
Short list, and we handle the rest.
Environment
Staging or production
Either works. We agree the environment, test windows and safety rules together. Most clients pick a production mirror with representative data.
Accounts
Two accounts per role
Two per role lets us test user to user boundaries properly, which is where the serious findings usually are. Include admin, if admin exists.
Context
Fifteen minutes of your time
A short walkthrough of what the application does and what would hurt most if it leaked. That single call reliably changes what we find.
Questions
The usual
questions.
How long does a web application penetration test take?
Most applications take one to two weeks of active testing, depending on the number of roles, endpoints and workflows. You get a fixed timeline and a fixed price before we start.
Do you test on production or staging?
Either. We agree the environment, the test windows and the safety rules in the scoping call. Production testing is common and safe under agreed rules.
Do you follow the OWASP Top 10?
We cover it, but we do not stop at it. The OWASP Top 10 is a category list, not a methodology. Business logic abuse, tenant isolation and chained findings sit outside it and are frequently where the real risk is.
Will the test disrupt the application?
No. We never run destructive or denial of service payloads without explicit written sign off, and we agree safety rules before testing begins.
Can you test a single page application or a React front end?
Yes. Modern front ends move most of the risk to the API behind them, which we test as part of the same engagement. See also our API penetration testing.
Brief us on the application.
A senior operator replies within one business day. No sales pipeline, no bot.