Six questions · ten minutes

Start your test

Tell us what to test, who to log in as, and how hard to push. Everything else — scope, pacing, OWASP mapping, the report itself — is ours to work out.

What should we test?

Fill in the address you would like us to look at. Up to 5 — a marketing site and its app are two separate targets.

Target 1
Address
What is it?
What kind of target is target 1?
WebsiteAPI
Anything a browser renders — marketing site, web app, admin panel.

Anything we should know?Optional

Two or three sentences here might change what gets tested more than any other field on this page.

About the application

The three most useful things to say

What the app does and what it is built with.
Whether several companies or teams share it, and what must never leak between them.
Any feature that would be embarrassing for us to trigger.

Who should we log in as?Optional

Most of what is worth finding sits behind a login. Without one we can only test what a stranger can reach.

No login — we test as an anonymous visitor

That is a valid test, and plenty of real issues live on the public surface. But everything behind your sign-in page stays untested.

How far should we go?

This is the ceiling on what we are allowed to do. We may always do less; we never do more.

What are we testing against?

ProductionReal users and real data. We slow down, self-throttle harder, and stay conservative about anything risky.Staging or testA copy nobody depends on. We can work faster and push harder within the depth you choose.

How hard should we push?

Look, don't touchWe observe and map. Nothing is sent that could change anything.Test properlyThe usual choice. We log in and probe for real weaknesses, but never change your data.— Everything above, plus injection and access-control probing— Content discovery, OWASP-aligned automated scanning— Signs in with the logins you provideNothing is created, modified or deleted. Findings that can only be confirmed by writing are reported as unconfirmed.Prove itWe confirm findings by actually exploiting them, which means writing data.

Most customers choose “Test properly”. It finds the great majority of real issues without touching your data.

Anything we must never touch?Optional

Pages and features we will not send a single request to, even though they sit on a host we are testing.

Add something to avoidoptional

Press Enter to add.

Commonly excluded — a password reset emails a real person, and a bulk delete cannot be undone:

Where should the report go?

One PDF per target, written for the engineers who will fix things and the auditor who will check them.

Email address

What lands in your inbox

An executive summary a non-engineer can act on
Every finding with the evidence behind it and the steps to reproduce
Remediation guidance written for the people who will fix it
The full list of what was tested, including the checks that came back clean

Coverage is OWASP-aligned, and the report is built to serve as evidence in ISO 27001 and SOC 2 workflows.

Authorisation

I own the systems listed above, or I am authorised by their owner to have them security tested. I understand this authorisation is what permits the test to run.