OWASP A05
Testing for Security Misconfiguration
The category with the widest surface, because it spans every layer you did not write. Frameworks, cloud services, containers and infrastructure all ship with defaults chosen for convenience.
- Application, framework, cloud and container layers together
- Includes cloud storage and IAM exposure, not just headers
- Separates real exposure from cosmetic scanner findings
What security misconfiguration looks like in a real application
A team ships a new microservice using the framework's starter template. The template enables a metrics endpoint for local debugging. In production it sits behind the same load balancer as the API, unauthenticated, and returns environment variables including the database connection string. Nobody configured anything wrongly; somebody left a default in place.
The security misconfiguration variants we test for
- Debug and diagnostic endpoints reachable in production: health checks that leak configuration, profilers, metrics and framework consoles
- Verbose errors exposing stack traces, file paths, library versions and SQL fragments
- Default credentials and accounts on admin panels, databases, message brokers and management consoles
- Cloud storage exposure — public buckets, over-permissive object ACLs and directory listing
- Over-broad IAM where a service role can do far more than the service needs, turning a small compromise into a large one
- Missing security headers, and more importantly content security policies permissive enough to be decorative
- Permissive CORS that reflects arbitrary origins or allows credentials with a wildcard
- Container and orchestration defaults: privileged containers, mounted sockets, exposed dashboards and unauthenticated internal services
- Unnecessary services and features enabled because a template included them
How we test for security misconfiguration
This is the category where automation earns its place, and we use it deliberately for breadth: configuration analysis, header inspection, service discovery and dependency checks across the whole surface.
The manual work is separating exposure from noise. A missing header on an endpoint that returns no sensitive data and sets no cookie is not a finding worth your engineers' attention, and reports padded with those items are how vendors reach an impressive page count. We assess each item against what it actually exposes in your system, then report accordingly.
The higher-value manual work is reachability. An internal service is only a finding if something can reach it, so we test from the positions an attacker would realistically hold: unauthenticated on the internet, authenticated as a low-privilege user, and where scope allows, from inside the network.
Why the report length is misleading here
Misconfiguration findings are easy to generate in volume and easy to inflate. If you are comparing vendors, look at whether each item states the concrete exposure it creates. "Header not present" is an observation; "this header's absence permits the clickjacking path demonstrated below" is a finding.
How security misconfiguration gets fixed
- Build hardened base images and templates so a new service starts secure rather than being hardened afterwards
- Separate configuration by environment and fail startup when a production service detects debug settings
- Scope IAM roles to the specific actions a service performs, and review them when the service changes
- Put internal endpoints on a separate listener rather than relying on nobody knowing the path
- Codify configuration so drift is visible in review instead of discovered during a test
Common questions
Are missing security headers a serious vulnerability?
It depends entirely on what the endpoint does. On a page that renders user content and holds a session, a missing or permissive content security policy meaningfully increases the impact of a cross-site scripting flaw. On a static asset endpoint it is close to irrelevant. Headers reported without that context are the most common form of padding in penetration test reports.
Does this cover our cloud infrastructure or only the application?
It covers the cloud configuration that affects the application's security: storage exposure, IAM scope on the roles the application uses, network reachability of its services, and secrets handling. A full cloud security posture review across every account and service is broader work and we will scope it separately if that is what you need.
How is this different from a vulnerability scan?
A scan enumerates observable configuration and reports deviations from a general baseline. We do that too, then determine which deviations create real exposure in your architecture, and test reachability to confirm it. The output is a shorter list where every item is worth acting on.
Do you test our CORS configuration?
Yes. We check whether the origin is validated against an allow-list or reflected back from the request, whether credentials are permitted alongside a permissive origin, and whether subdomain matching is loose enough that any subdomain you do not control becomes a trusted origin. Reflected-origin-with-credentials is a common and genuinely serious finding.
Should we set a content security policy?
Yes, but a meaningful one. A policy permissive enough to allow inline scripts and arbitrary hosts satisfies a scanner and constrains nothing. Start in report-only mode to find what your application actually loads, tighten from there, and treat it as a mitigation that reduces the impact of a cross-site scripting flaw rather than as a substitute for output encoding.
Do you need access to our cloud console?
Not necessarily, and we test from an attacker's position by default. Read-only access to configuration makes the work faster and the remediation guidance far more precise, particularly on IAM scope and storage permissions, because we can tell you which policy to change rather than describing what we observed from outside. It is your call and we scope both ways.
How do we stop misconfiguration from coming back?
By making configuration a build artifact rather than a manual step. Hardened base images, environment-specific configuration that fails startup when production detects debug settings, and infrastructure defined in code so drift appears in a pull request. Otherwise every new service reintroduces the same defaults and each test finds them again.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.