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 append a single syntax-breaking character to a parameter and watch for a database error that was absent from the baseline response. Read-only — we never extract or modify data.

User input is reaching a SQL statement unparameterised. Even without extracting data, a returned database error confirms the query can be broken — a direct path to full SQL injection.

When a parameter returns no error and no visible change, we test for blind injection: we submit input asking the database to pause briefly only if a condition holds, and compare the response time to the baseline. A reliable, condition-dependent delay means the input is executed as SQL. Delays are minimal and bounded — never destructive payloads.

The database is injectable even though nothing is reflected back — the kind that error- and content-based checks miss entirely. An attacker can extract data one inference at a time.

We inject a bounded shell-arithmetic echo (e.g. $((1009×1013))) and check whether the server evaluated it — the computed marker appears only if a shell ran the input. We send nothing destructive: only harmless echo and arithmetic.

The application passes user input to an operating-system shell. This is typically full server compromise — an attacker can run arbitrary commands.

We inject read-only traversal sequences (../../etc/passwd and encoded variants) and check the response for well-known system-file signatures. Nothing is written or modified.

The application turns user input into filesystem paths without containment — an attacker can read files outside the intended directory (configuration, secrets, source).

We inject a bounded arithmetic marker for the common template engines ({{1009*1013}}, ${…}, <%= … %>) and flag it only when the server evaluates the expression — the product appears while the literal does not. No code-execution payloads are sent.

User input is rendered as template source. SSTI frequently escalates to remote code execution.

For URL-like parameters we substitute a cloud-metadata address and check whether the metadata response is reflected back (reflected SSRF). We also substitute a unique Aegis out-of-band callback URL and detect whether the server makes a request to it (blind SSRF — where nothing is reflected). The callback records only that the token was reached.

The server fetches attacker-controlled URLs. This commonly exposes cloud credentials and internal services that are unreachable from the outside.

For endpoints that accept XML, we submit a document defining an external entity pointing at a unique Aegis out-of-band callback URL, then watch whether your parser resolves it and calls us. The callback records only that the token was reached — we never read local files or exfiltrate data. Because this sends a POST body it is an opt-in heavier probe you approve explicitly.

Your XML parser resolves external entities. That can read local files (including secrets), reach internal services (a form of SSRF), and in some parsers escalate further.

For parameters that control a destination URL, we substitute a benign external marker and check whether the application issues a redirect to it. Read-only — we observe the redirect target, we don't follow it anywhere harmful.

An attacker can craft a link on your own domain that silently forwards users to a site they control — a strong aid to phishing, and sometimes a token-theft vector when chained with OAuth or SSO flows.

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. This needs test logins for both tenants, so it takes a few setup steps: you supply those logins and approve the run in-app. It is fully self-serve — just multi-step rather than one-click. (The underlying dual-identity engine that powers it is live self-serve for same-app IDOR — see §9.)

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.