External penetration testing

External penetration testing

We test what the internet can reach: your public web apps, APIs, admin panels and login flows. We test from outside, with no inside access, inside a scope you authorize.

What we test

• Public web apps and APIs: each domain you put in scope.
• Admin panels and login pages: who can reach them, and what weak sign-in or reset flows allow.
• Browser protections: HSTS, cookie flags, framing rules and redirects.
• Server-side requests: features that fetch a user-supplied address, such as URL previews.
• Request handling: host header use, rate limits on login, and files such as security.txt.

Where it stops

This is an outside view of web-facing systems. We do not test internal networks or physical sites. We do not run social engineering against staff, and we do not run denial-of-service or load tests. If you want to know whether an attacker with a user account can go further, ask for a web application test as well.

What it looks like

We start with the list of domains you authorize. We map what answers, then test each service as an anonymous visitor. If you give us accounts, we repeat the key tests as each role. Out-of-scope hosts are not touched.

What to have ready

• A list of the domains you authorize, and any that are off limits.
• A contact who can answer during the test window.
• Test accounts, if you want signed-in checks.
• The reason for the test, such as a customer request or an audit.

Why test from outside

An outside attacker starts with what your domains show. A forgotten admin page, a login with no limit or a preview feature that fetches any address is enough to start. This view matches where a real attack begins.

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 evidence, reproduction steps and a fix. The report also lists the controls that held. Read the sample 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.

• HSTS: test the Strict-Transport-Security header
• Host header injection: a password-reset test
• Clickjacking: a local frame-ancestors test
• API rate limiting: how to test a login limit
• security.txt: RFC 9116 rules and checker

Questions

What is the difference between external and web application testing?

External testing looks at what an outsider can reach with no account. Web application testing goes deeper, as each signed-in role. Many teams buy both. See penetration testing services.

Do you test internal networks?

No. We test web-facing systems that you authorize in writing.

What do you need from us?

The domains in scope and a contact for the test window. If you want signed-in tests, add one account for each role.

Will you test production?

We can, with tighter limits. We agree the limits in the scope.

How much does it cost?

We quote the scope in writing after a short call. We publish no prices.

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