Every test we run, what it means, and exactly how to fix it.

We request your site over HTTPS and inspect the response for a Strict-Transport-Security header, checking max-age and whether subdomains are covered.

Missing: a visitor's first request — or one where an attacker strips TLS on a hostile network — can travel over plain HTTP, exposing the session cookie. Present: browsers refuse HTTP for your domain entirely after the first visit.

We read response headers across several pages — not just the homepage, since headers are often applied inconsistently by route.

No nosniff: a browser may guess a file's type and execute an upload as script. No Referrer-Policy: full URLs (which may carry tokens or IDs) leak to third-party sites. No Permissions-Policy: embedded content can request camera, microphone or location.

We inspect every Set-Cookie for Secure, HttpOnly and SameSite, and identify which cookie carries the session.

No Secure: the cookie can be sent over plain HTTP and captured. No HttpOnly: any JavaScript — including injected script — can read your session token. No SameSite: the browser attaches the cookie to cross-site requests, enabling CSRF.

We parse your CSP and evaluate the script-related directives, flagging unsafe-inline, unsafe-eval, overly broad wildcards and a missing frame-ancestors.

CSP is the seatbelt for cross-site scripting. A missing or permissive policy doesn't create a vulnerability — it removes the control that would have contained one. With unsafe-inline, an injected <script> executes exactly as the attacker intended.

We send cross-origin and preflight requests with varied Origin values to see which are accepted, and whether credentials are permitted.

The dangerous combination is reflecting any origin and allowing credentials — that lets any website read authenticated responses on behalf of a logged-in visitor. Access-Control-Allow-Origin: * without credentials is usually fine for public data.

We crawl the reachable application — authenticated, on paid tiers — inventorying URLs, methods, parameters and forms, then compare against your OpenAPI specification if you provide one.

Endpoints live in production that aren't in your spec. Undocumented routes escape design review and access-control decisions — historically a common source of forgotten admin and debug endpoints.

We submit pairs of logically true and false conditions to each parameter and compare responses. A page that changes between always-true and always-false is evaluating input as SQL. We use inert boolean logic — never data-modifying or destructive payloads.

An attacker can read, and often modify, your database directly — every customer record, password hash and payment detail. This is as serious as application security gets.

We submit a harmless unique marker and check whether it is reflected into the response, and in what context — HTML body, attribute, or JavaScript. We never inject working exploit code.

Reflected and unescaped in an executable context: an attacker can run JavaScript as your users — stealing sessions, altering pages, exfiltrating data. Reflected but correctly escaped: not a vulnerability, but a place to keep encoding correct as the code changes.

We sign in as two identities — typically a low-privilege user and a higher-privilege one — then replay identical requests as each and compare. If the low-privilege session receives data it shouldn't, that's broken access control. We check the final response, not just the status code, because many apps return HTTP 200 while redirecting to a "no access" page.

Broken access control is the most common serious flaw in modern applications, and automated scanners rarely find it because it requires understanding who should see what. A hit here means one customer can reach another's data, or an ordinary user can perform privileged actions.

Where a resource is addressed by an identifier (/invoices/1024), we request neighbouring identifiers as a user who should not have access.

Records can be enumerated by changing a number in the URL — a trivial attack requiring no tooling.

We attempt real state-changing actions as the wrong role — approving one's own request, triggering a payment without finance rights, acting on another party's order. Each attempt is bounded and logged, with a cleanup contract.

These are the flaws that cost money rather than data: self-approved purchases, unauthorised payments, tampered orders. Scanners essentially never find them, because they require understanding your workflow — this is the closest automation gets to a human tester.

We submit state-changing requests without a valid token, and with a token belonging to a different session, to see whether they are accepted.

Another website can make your logged-in users perform actions without their knowledge — changing an email address, transferring funds, approving a request.

With two tenants provisioned, we take an authenticated session from tenant A and replay it against tenant B — including by manipulating the host, subdomain or tenant identifier — and separately attempt to fetch tenant B's records by identifier.

For a SaaS business this is the existential control. A failure means one customer can read another's data — typically a breach-notification event and, often, a company-ending one.