Home / Knowledge hub / Cloud misconfiguration
Knowledge hub
Cloud misconfiguration
A cloud setting left unsafe, such as open storage or an overly broad permission.
What it means
Cloud misconfiguration is any cloud setting that leaves a resource less safe than intended. Examples are storage open to the internet, a database reachable from anywhere, a permission that allows every action, a disabled log, or a default password never changed.
The cloud makes resources easy to create and easy to expose. A setting that works in a test is copied into production, or a quick change to fix an outage is never undone. The software is working as configured. The configuration is the weakness.
Why it matters
Misconfigurations are among the most common causes of cloud data exposure because they require no special skill to find, only a scan and some patience. Open storage, exposed admin panels and broad roles are found by automated tools within hours of appearing, so a mistake can be exploited before your own team has even noticed it.
OWASP lists security misconfiguration as its own category in the Top 10. Each miss can mean a data breach, a compromised account, or a failed audit, and each one is simple to fix once someone sees it. The hard part is seeing it at all.
How it shows up
You meet it in storage, networks and security groups, identity and access, databases, containers, logging and serverless functions. Causes repeat: settings changed by hand and never recorded, defaults left in place, copied examples, and no review when a team creates something new.
Define infrastructure as code so changes are reviewed, run a posture tool that checks settings against a baseline, alert on drift, and limit who can change production. Test from outside as well, because what is actually reachable differs from what people believe is configured.
Questions people ask
Cloud misconfiguration, answered
What are common examples of cloud misconfiguration?
Public storage buckets, databases open to the whole internet, security groups allowing all traffic, over-broad roles, disabled logging, unencrypted data stores, and unused keys left active. Each is a setting, not a software bug.
Is cloud misconfiguration the cloud provider's fault?
Usually not. Under the shared responsibility model, the provider secures the platform while you configure and secure your own resources. Provider defaults have improved over the years, but your own settings remain yours to review.
How is it found?
By comparing your settings against a baseline with a posture tool, by reviewing code that defines your infrastructure, and by testing from outside to see what is actually reachable. The three views catch different mistakes.
Does infrastructure as code prevent it?
It helps by making changes reviewable and repeatable, but it can also repeat a mistake at scale. Scan the code before it is applied, and check the live result, since people still change things by hand.
Is it a vulnerability?
It is a weakness, and the OWASP Top 10 lists security misconfiguration as a category. Whether it becomes an exploitable vulnerability depends on whether a reachable path leads to data or control.
Sources
Where this comes from
Related
Terms that sit next to this one
CSPM
Tools that keep checking your cloud settings against security good practice.
Infrastructure as code
Describing servers and networks in files so they can be reviewed and repeated.
S3 bucket exposure
A cloud storage bucket left open so anyone on the internet can read its files.
Shared responsibility model
The split between what your cloud provider secures and what you must secure yourself.
Infrastructure drift
Live systems slowly differing from what your code says they should be.
What is exposed that you did not intend?
Misconfigurations are best found from outside, as a stranger sees your app. We report what is reachable and what we actually retrieved, with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.