Misconfiguration scanner
Find the misconfigurations that fail audits.
The OWASP A05 category that causes the most audit findings. Barrion catches it before the auditor does, continuously.
What we check
Every place a default becomes a finding.
TLS
TLS / HTTPS
Wrong cipher suite, expired certificate, missing HSTS, mixed content, OCSP stapling absent.
Headers
Security headers
Missing CSP, weak X-Frame-Options, no Permissions-Policy, broken Referrer-Policy, COOP/COEP/CORP gaps.
Cookies
Cookie flags
Missing HttpOnly, missing Secure, weak SameSite, no Partitioned attribute.
CORS
CORS policy
Wildcard Access-Control-Allow-Origin, mis-scoped allow-credentials, missing Vary: Origin.
DNS / Email
DNS & email auth
Missing SPF, broken DKIM, no DMARC enforcement, no CAA records.
Framework
Framework defaults
Server header leaking version, X-Powered-By exposed, debug pages reachable.
Why automated catches it
Misconfigurations are a checklist problem.
- ✓Misconfigurations are deterministic: a header is either there or it isn't
- ✓Scheduled scans catch them after a deploy regresses
- ✓Each finding includes the exact remediation step for your framework
- ✓Auditors love this category because the evidence is unambiguous
- ✓Score-impact ranks them by how much they hurt your overall posture
Scan vs pentest
A misconfiguration scan stops at the surface.
A misconfiguration is something a scan can see: the header is there or it isn't. Whether a loose CORS policy or a leaked version banner actually lets someone read another customer's data is a different question, and only an active test answers it.
Barrion's AI pentests test your web app and APIs the way an attacker would, including the access-control and injection flaws a passive scan can't reach. Findings are checked against your live app before they're reported. The pentest can rerun on a schedule you set, and labels each finding new, still open, resolved or regressed. More on AI pentesting and on continuous pentesting.
FAQ
Misconfigurations, answered.
What counts as a 'security misconfiguration'?
A security misconfiguration is any setting that's wrong, weak, or missing on a component you operate: a missing security header, a CORS policy with wildcard Access-Control-Allow-Origin, a cookie without HttpOnly, an SPF record that ends in ~all instead of -all, a TLS configuration that still allows TLS 1.0. OWASP groups these under category A05 of the Top 10. They're the most common audit finding by a wide margin because they're deterministic, observable, and easy to introduce by accident.
Why are misconfigurations so common?
Frameworks ship with permissive defaults that work for development but need to be tightened for production. Cloud services expose toggles that change behaviour silently. Every deploy introduces an opportunity for a regression. Most teams don't have a security engineer reviewing every config change, so misconfigurations accumulate until something fails an audit or worse, until someone exploits them. Continuous monitoring is the right operational answer because the bug class is checklist-shaped.
Does Barrion only flag missing pieces, or does it actually rank severity?
Each misconfiguration is severity-ranked by its real-world impact. A missing HSTS header on a payment page is critical, while a missing Permissions-Policy on a static landing page is low. Severity is computed from CVSS-derived impact weighted by what the page actually serves. Findings appear in priority order in the dashboard and PDF, so you triage what matters first rather than walking down a flat list.
What's the fastest fix path for the most common findings?
Each finding includes a step-by-step remediation written for your framework. For Next.js the CSP fix is a middleware tweak, for Django it's a settings.py change and for Laravel it's a middleware addition. The remediation isn't OWASP boilerplate, it's the exact code or config change for the stack the scanner detected. Most teams resolve their top 5 critical findings within a single sprint.
Do auditors really care about missing security headers?
Yes, and increasingly so. SOC 2 CC6.6 and CC6.7 both reference transmission and integrity controls. ISO 27001 Annex A 8.24 (Use of cryptography) and 8.16 (Monitoring) point at header and TLS hygiene. PCI DSS Requirement 6.4.5 specifically calls out HTTP security headers and TLS configuration. NIS2 risk-management expectations include 'state of the art' technical measures, which auditors interpret to include standard hardening headers. Missing headers are a top-3 finding category in modern security audits.
Scan for misconfigurations now.
Your first passive scan is free. Sign up to schedule recurring scans across every domain you ship.