We point Aegis at our own production — and publish the result.
The fastest way to trust a security tool is to watch it test the people who built it. So we run the exact engine our customers get against our own live platform, and we tell you what it found — including the gaps we then fixed. If we won't dogfood it in public, why would you trust it on your app?
What we fired at ourselves
The aggressive detector suite, aimed at our public marketing surface, the customer portal and every public API endpoint — the same classes we run for a paying Go-Live Assessment.
Injection, every class
SQL injection (boolean, error and time-based), cross-site scripting, template injection, path traversal and command injection — fired at every reachable parameter and form field.
Out-of-band & server-side
Server-side request forgery (reflected and blind, via an out-of-band callback collector) and XML external entity injection — the checks that catch what a response body alone never shows.
Auth, headers & disclosure
Authentication-endpoint probing, error-based information leakage, stack-trace exposure, security-header posture and Host-header handling across the whole public surface.
Clean where it counts — and we fixed what it flagged
No injection of any class. No SSRF or XXE callbacks. No authentication bypass, no stack traces, no error-based leakage. Cross-tenant isolation held — a second tenant could not reach the first tenant's data. Where our own scan flagged hardening items — security-response headers and session-token claims — we shipped the fix. That's the loop we sell: find, then fix.
| Check | Result | Action |
|---|---|---|
| Injection (SQLi · XSS · SSTI · path · command) | No findings | — |
| SSRF (reflected & blind) · XXE | No findings | — |
| Cross-tenant object access (IDOR/BOLA), two identities | Held | Tenant isolation verified |
| Auth-endpoint probing · error/stack-trace leakage | No findings | — |
| Content-Security-Policy & framing headers | Hardening | Set app-wide |
Session-token claims (JWT iss/aud) | Hardening | Added |
| Host-header handling | Fail-closed | Verified — non-canonical hosts are refused |
Latest run 18 August 2026 — the full aggressive suite against a complete Aegis instance (all 231 API routes, 24 test classes). We re-run this on every meaningful change and keep this page current.
"Nothing found" is only worth trusting if the tools can find things
Any scanner can return zero by simply not looking. Two things make our clean results credible — and they're baked into every customer report, not just this page.
Positive controls
We validate the engine by planting known-vulnerable routes into a disposable test build and confirming the detectors catch every one. A suite that reliably catches planted bugs is a suite whose silence you can trust. A clean result is coverage, not blindness.
Verified Controls, in the report
Every Aegis report includes a Verified Controls section — the specific attacks we attempted and the target held against. It's the evidence a reviewer needs to accept a clean result, and it's the section the incumbents don't give you. See how it works →
Point the same engine at your app.
Verify a domain, accept the rules, and Aegis runs the exact suite you just saw us run on ourselves. Free to start.