Skip to content
SECQON
How it worksWhat we checkPricingSecurity
Log inStart free

Automated web application penetration test — what SecQon's Deep scan actually tries

The Deep profile is SecQon’s automated web-application test. It crawls your app in a headless browser, then tries a bounded set of attacks where a proof is possible without harm: an inert HTML element to show reflected markup renders, a boolean SQL-injection test that reads no data, and an out-of-band callback for SSRF. The penetration-test tier (Business, or the one-off pentest report) adds an active scanner with 13 allow-listed rules and a WAF measurement. It is automated external testing with a validation layer — not a human red team — and the report is precise about which of these stages actually ran.

Runs on
Deep (Growth and Business, and the one-off pentest report). The active scanner, WAF measurement and API account tests run on Deep + pentest, which needs Business or the one-off report and a separate acknowledgement.
Included from
Growth plan ($149)
OWASP Top 10 (2021)
A01A03A05A06A08A10

What we test

Why it matters

Headers, certificates and open ports tell you how well the doors are locked. A web-application test asks whether the application itself can be made to misbehave — whether user input can end up running in someone else’s browser, reaching your database as code, or making your server fetch URLs on an attacker’s behalf. Those are the flaws that turn into data breaches, and they live in your code, not your configuration.

The difference between a noisy scanner and a useful one is proof. SecQon separates what it demonstrated from what it merely observed. A finding is “demonstrated” only when a bounded proof changed how your application behaved — the rendered markup, the SQL differential or the SSRF callback. A condition a re-test reproduced is “confirmed”, and anything else stays likely or unconfirmed. A clean application reads “0 demonstrated”, not a list of scary-sounding guesses.

It is also designed to be run against the production system your customers use. Every request passes a scope guard pinned to your verified hosts, the rate is capped per asset, and destructive options — shells, file writes, data dumps — are blocked before a tool can start. Deep needs a separate acknowledgement for each scan, or a standing authorisation for the monthly re-audit that you can withdraw at any time.

An example finding, and its fix

A finding of a type this check really produces. The evidence is illustrative, not taken from a customer's scan.

High

SQL injection in parameter 'id'

Evidence

Stability control: GET /products?id=7 → 200, body stable across repeat requests
TRUE:  GET /products?id=7 AND 1=1 → 200, body matches baseline
FALSE: GET /products?id=7 AND 1=2 → 200, product listing absent
Technique: boolean-based (detection only; no data read)

How to fix it

Find the query that uses the id parameter in the /products handler. Replace string-built SQL with a parameterised query or your ORM’s query builder, so the value is always passed as data. Validate id as an integer before it reaches the database. Check other handlers built the same way, then re-test the finding from your report.

What we don't test

  • Business logic, such as whether a discount can be applied twice or a workflow skipped. No automated external test can judge this.
  • Race conditions and stored (persistent) XSS. Both are deliberately excluded.
  • Chaining findings into multi-step attack paths.
  • Password guessing, brute force, lockout, password policy or MFA. We never submit a credential to your login.
  • The template sweep and SQL-injection test behind your login. Signed-in pages are crawled and checked by our own checks only; multi-step or recorded login flows are not supported.
  • More than 35 URLs in the expensive assessment stages of one scan. Any shortfall is stated in the report.

Every report names what its scan did and did not assess. See the full OWASP Top 10 coverage, including the two categories no external scan can assess.

Web application pentest: questions people ask

Is an automated pentest a replacement for a manual penetration test?

No. It runs a defined, published set of automated external tests, and the report says which ran; it is not a human tester chasing business-logic flaws or chaining findings. You can run SecQon continuously and still commission a human pentest when a contract or auditor asks for one.

Is a Deep scan safe to run on production?

It is built for that. Every request is checked against your verified hosts and rate-limited, the SQL-injection test reads no data, and destructive options are blocked before a tool starts. It does send attack-shaped input, which is why each Deep scan needs your explicit acknowledgement.

How long does a Deep scan take?

Hours rather than minutes. A Deep scan of a 14-URL site of ours took about 4.2 hours. The scan runs in the background, so nothing in your browser has to stay open.

What does “demonstrated” mean compared with “confirmed”?

Demonstrated means a bounded proof changed your application’s behaviour — rendered markup, a SQL differential or an SSRF callback. Confirmed means a re-test reproduced the condition, which is often a configuration fact rather than an exploit.

Does SecQon test pages behind my login?

On Growth and above, yes: with a stored session cookie or token, the crawl and SecQon’s own checks run signed in. The template sweep and SQL-injection test do not, and recorded multi-step logins are not supported.

Does Deep run automatically on a schedule?

Not by default. Daily monitoring is always non-intrusive. You can authorise the monthly re-audit to run Deep for a specific asset, inside a time window you choose (default 01:00–05:00 UTC), and withdraw that at any time.

Other checks

  • TLS & certificates

    Certificate trust and expiry, and whether your server still accepts TLS 1.0 or 1.1.

  • Security headers & cookies

    Missing or ineffective HSTS, CSP, clickjacking, nosniff and Referrer-Policy headers, plus cookie flags.

  • DNS & email security

    SPF, DMARC, CAA and DNSSEC — the records that stop spoofed email and mis-issued certificates.

  • Exposed ports & services

    36 high-risk TCP ports — databases, container control planes, remote admin — checked with one connect each.

  • API security

    Your API’s own schema, read as an outsider: open operations, GraphQL introspection, CORS and leaked stack traces.

Last reviewed against our scanning documentation on 24 Sep 2026.

See what a scan finds on your own asset

Free for one verified asset, no card needed. Paid plans add the written report, more assets and deeper scans.

Start freeCompare plans