Penetration testing

Penetration testing services

We attack your web app, API or SaaS product the way an outsider would, inside a scope you authorize in writing. You get a report with proof and a fix for each finding.

What we test

• Web applications: sign-in, sessions, roles, forms, uploads and the JavaScript the browser runs.
• APIs: who may read or change which record, on every endpoint in scope.
• Multi-tenant SaaS: whether one customer's account can reach another customer's data.
• AI features: LLM apps, agents and MCP servers, as scoped assessments. See AI red teaming.

Who it is for

A CTO who must know what an attacker can reach before a launch. A CISO who owes a customer a test report. A founder who needs penetration test evidence for a SOC 2 audit. We write the report so a non-specialist can read the summary and an engineer can reproduce each finding.

How we test

We test the running system from the outside, as each user role in scope. We send direct HTTP requests, run tests in a real Chromium browser, read the client-side JavaScript and compare anonymous and signed-in requests. To prove a change crossed accounts, we read it back from a second account. Our AI testing agents run the repetitive requests. People check the evidence for each finding and write the report. See AI penetration testing.

Pick the service that fits

• Web application penetration testing for browser-facing products.
• API penetration testing for REST and other HTTP APIs.
• External penetration testing for what the internet can reach.
• AI red teaming for LLM apps, agents and MCP servers.

What to have ready

• The domains and apps in scope.
• One test account for each user role.
• An OpenAPI file, a Postman collection or a GraphQL schema, if you have one.
• The reason for the test and the date you need the report.
• A staging environment with realistic data, if you have one.

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

You get the report as HTML, PDF and Markdown, with proof-of-concept scripts. It has a plain summary, one section per finding, the controls that held, a remediation plan and the limits of the test. Read the sample report. It is a full report, written for a fictional app.

• 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.

• Authorization testing for APIs
• IDOR: a local example with PUT and DELETE
• Broken access control: vertical privilege escalation
• Tenant isolation testing: three gaps beyond IDOR
• OWASP API Top 10: tests you can run

Questions

What does a penetration test cost?

We publish no price list. We quote the scope you have, in writing, after a short scoping call. The call and the quote are free. See how we quote.

Do you test production?

We can. Production needs tighter limits and more coordination, so a staging environment with realistic data is better if you have one. We agree this in the scope.

Will the report work as SOC 2 evidence?

The report states the scope, method, findings and retest results. Your auditor decides what evidence they accept, so ask them first. We do not certify anything.

Do you retest fixes?

Yes. The quote states which findings we retest and when.

What do you not test?

Internal networks, physical sites, social engineering of staff, and denial-of-service or load tests.

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