Web application penetration testing

Web application penetration testing

We test your web app in a real browser and over raw HTTP, as each user role in scope. You get proof, a fix and a retest for each finding.

What we test

• Sign-in and sessions: login, password reset, 2FA, session lifetime, cookie flags.
• Access control: what each role can read or change, and what an anonymous visitor can reach.
• Input handling: SQL injection, stored and reflected XSS, file paths, redirects and server-side requests.
• Browser-side flaws: CSRF, clickjacking and anything in the client-side JavaScript.
• Workflows: checkout, coupons, invites and uploads, including race conditions.

What it looks like

We run the app with the accounts you give us, one for each role. For each flow we send the normal request, then change it: another user's identifier, a lower role, no session, a replayed token. Flaws such as CSRF and stored XSS only show up in a browser, so we test those in real Chromium.

What counts as a finding

A "success" response is not proof. If a request claims to change another account's record, we read that record back through the other account. We also send control requests, such as bad identifiers and anonymous calls. The report lists the controls that held, so your fix does not break a protection that already works.

What to have ready

• The domains in scope, and which ones are off limits.
• One test account for each role, plus a second account in the same role to test cross-account access.
• The flows that matter most: payments, invites, uploads or admin tools.
• The date you need the report, and who will read it.

How an engagement runs

1. Scoping call. A short call about what you need, who will read the report and your deadline. We send a written scope and a quote.
2. Authorization. Testing starts only after the owner of each system signs written authorization. Do not send passwords or keys.
3. Testing. We test inside the agreed scope, with test-owned accounts and data.
4. Report. You get evidence, reproduction steps and a fix for each finding.
5. Retest. After you ship fixes, we can verify them. The quote states the retest terms.

Safety limits

• We test only with written authorization from the system owner.
• Destructive proofs use only accounts and records we create for the test, marked as test data.
• Tests of uploads, password guessing, email sending and paid third-party APIs have limits, and the report states what they cost.
• Reproduction scripts are read-only where possible.

What you get

A report in HTML, PDF and Markdown, with proof-of-concept scripts. Each finding has a cause, an impact, the requests and responses, reproduction steps and a fix. Read the sample report, written for a fictional app. For the wider method, see application security assessment.

• Scope, assets and a four-level severity scale: Critical, High, Medium and Low
• An executive summary with priority actions
• One section per finding: description, impact, verified results, reproduction and fix
• Controls that held, so your fix does not break them
• A remediation plan, plus limitations and open questions

Proof from our own research

Each post below has a local fixture with real recorded requests and responses. The code is public in web-security-fixtures on GitHub.

• SQL injection: login bypass and UNION reads
• CSRF: a local SameSite cookie experiment
• Session fixation: a local curl experiment
• 2FA bypass testing for your own login flow
• Open redirect: testing a ?next= login fix

Questions

What do you need from us?

The domains in scope, one test account for each role, and any API description you have. A staging environment with realistic data helps. Do not send passwords or keys through the form.

Do you test single-page apps and JavaScript-heavy sites?

Yes. We test in a real browser and read the client-side JavaScript.

Is the test black-box?

By default, yes. We test the running system from the outside. If you can share documents or source access, say so on the scoping call.

How much does it cost?

We quote the scope in writing after a short call. We publish no price list. The call and the quote are free.

Do you also test the API behind the app?

Yes, if it is in scope. See API penetration testing.

To see how a quote is built, read pricing. For the full method, read application security assessment.