Attack Resilience: How QuantumVerifi Probes Your Website for Misuse Resistance

Traditional security scanners check for known CVEs and missing headers. That's table stakes. Attack Resilience goes further — it probes your live website with 40+ adversarial payloads to measure how well your application actually resists being misused.

No configuration. No credentials. No agents to install. Point QuantumVerifi at a URL and get a resilience score in under 3 minutes.

What Gets Tested#

Attack Resilience covers three domains, each weighted in the final score:

Web Resilience (35%)

Cross-Site Scripting (XSS) — 8 payload variants test whether user input is reflected unescaped in the response. Basic <script> tags, <img onerror> handlers, SVG injection, attribute breakout, and template injection. If any payload appears unescaped in the rendered page, that's a confirmed resilience gap.

CSRF Protection — Checks whether POST forms include anti-forgery tokens. Missing CSRF protection on state-changing forms is a resilience signal, not a theoretical vulnerability.

Path Traversal — Dot-dot-slash sequences, URL-encoded variants, and null byte injection test whether file system boundaries are respected.

Open Redirects — Protocol-relative URLs and encoded redirects test whether the application follows attacker-controlled redirect targets.

Information Disclosure — Probes for .env file exposure, .git directory access, server version headers, debug endpoints, and stack traces in error responses.

API Resilience (30%)

Auth Boundary Probing — Creates a fresh browser session (no cookies) and attempts to access authenticated routes. If protected content is served without authentication, that's a gap.

Rate Limiting — Rapid burst requests test whether the application throttles abuse.

Schema Manipulation — Extra field injection (mass assignment), type confusion, and nested object injection test API input validation boundaries.

Note: API weight drops to 15% if no authenticated flows are discovered — the score adapts to your actual attack surface.

Input Resilience (35%)

SQL Injection — Error-based (single quote, comments, UNION), time-based blind, and boolean blind injection. Detection combines SQL error patterns in responses with timing anomalies (response > 5s AND > 3x baseline).

Boundary Values — Overlong strings (10KB), empty fields, negative numbers, float overflow, and NaN test how the application handles edge-case input.

Encoding Abuse — Null bytes, Unicode homoglyphs (Cyrillic 'a' vs Latin 'a'), UTF-8 overlong encoding, and double URL encoding test input normalisation.

Type Confusion — Strings in number fields, arrays in string fields, booleans in text fields test schema enforcement.

Email Boundary — XSS in email fields, SQL injection in email fields, missing @ symbol, and overlong email addresses test email-specific validation.

How It Works#

Phase 1: Form-Based Probing

QuantumVerifi iterates over forms and inputs discovered during crawling. Payloads are selected based on the input type — email fields get email-boundary payloads, search fields get reflection payloads, generic text fields get injection payloads.

For each probe:

1. Capture baseline response time
2. Inject payload into the target field
3. Submit the form
4. Analyse the response for reflection, error signatures, timing anomalies, or missing protections

Phase 2: URL Parameter Probing

Path traversal, redirect boundary, and information disclosure payloads are tested via URL parameters. QuantumVerifi constructs URLs like /?q=../../../etc/passwd and /?redirect=//evil.com, then checks whether the application serves file content or follows attacker-controlled redirects.

Phase 3: Auth Boundary Probing

A fresh browser context (no authentication cookies) attempts to access every authenticated route discovered during crawling. Routes that serve content without redirecting to login are flagged as auth boundary gaps.

Safety by Design#

Attack Resilience is built to be safe for production:

QuantumVerifi probes your application the way an external attacker would — through the browser, respecting the same constraints. Nothing is modified, deleted, or stored on your server.

Reading Your Results#

The Score (0–100)

Each probe produces one of four outcomes:

The per-category score is (defended / total probed) * 100, then weighted by category importance. The final score adapts to your attack surface — if your site has no forms, form-based attacks don't penalise your score.

Category Breakdown

The report shows three category cards:

• Web Resilience — XSS, CSRF, path traversal, redirects, info disclosure
• API Resilience — Auth boundaries, rate limiting, schema manipulation
• Input Resilience — SQL injection, boundary values, encoding abuse, type confusion

Each card shows the category score, number of probes run, and confidence level.

Findings

Each finding includes:

• Severity — Critical, serious, or moderate
• Confidence — How certain the detection is (high/medium/low)
• Detection method — Reflection, error signature, timing anomaly, or auth behaviour delta
• Replay steps — Exact steps to reproduce the finding manually
• Screenshot — Visual evidence captured at the moment of detection
• Remediation — What to fix and how

Defended Behaviours

Positive evidence matters too. The report lists every probe that was successfully defended, with the specific defence mechanism observed:

• input_escaped — Payload was HTML-encoded in the response
• request_rejected — Application returned 400/403
• rate_limited — Application throttled the request
• timing_neutralized — No timing anomaly detected
• header_ignored — Server version headers not exposed

These are useful for compliance reporting — evidence that your defences are working.

Scoring Examples#

Grade A (90+): All XSS payloads are escaped, SQL injection returns no error patterns, auth routes redirect to login, CSRF tokens are present on all forms. Minor gaps might exist in encoding edge cases.

Grade C (70–79): Core protections are in place but gaps exist. Common pattern: XSS defended on main forms but reflected in search parameters, or auth boundary is solid but rate limiting is missing.

Grade F (<60): Multiple categories have significant gaps. Common for applications with no input sanitisation framework, missing CSRF protection, or exposed debug endpoints.

Comparison: Attack Resilience vs Security Scan vs AI Resilience#

All three run automatically as part of every URL analysis. Together they provide a complete picture: static security posture, dynamic resilience to attack, and AI-specific vulnerabilities.

Getting Started#

Attack Resilience runs automatically on every URL analysis — no configuration needed. The more forms, inputs, and authenticated routes your site has, the more comprehensive the testing.

To get the most out of it:

1. Use authenticated crawling if your application has login-protected features — Attack Resilience tests auth boundaries from both sides
2. Check the replay steps for each finding — they're copy-pasteable manual reproduction steps
3. Track your score over time — the trending chart shows Attack Resilience alongside other quality metrics
4. Export findings via PDF or the API for security reviews and compliance reporting