Security Misconfiguration in 2025: Why It's Now the #2 Web App Risk
Security Misconfiguration in 2025: Why It's Now the #2 Web App Risk
TLDR: The Internet Archive — 27 years of preserved internet history — was breached in October 2024 because of a GitLab configuration file that sat exposed on a development server for nearly two years. One file. 31 million accounts compromised. 7TB of data stolen. Security Misconfiguration jumped from #5 to #2 on the OWASP Top 10 2025 for a reason — it's now the most pervasive vulnerability class in modern software. The worst part? Not a single line of bad code caused it.
One File. Two Years. 31 Million People.
In October 2024, a hacker found an exposed GitLab configuration file on one of Internet Archive's development servers — services-hls.dev.archive.org. The file had been sitting there, publicly accessible, since at least December 2022. Nearly two years.
Inside that file: an authentication token. With that token, the attacker downloaded the Archive's source code. Inside that source code: more credentials, more API tokens, database access keys. They used those to pull the full user database — 31 million records containing email addresses, screen names, and bcrypt-hashed passwords.
Then they used a Zendesk API token they found in the same source code to send phishing emails directly from Internet Archive's legitimate support system — emails that passed DKIM, DMARC, and SPF checks perfectly, because they were technically coming from the real server.
The hacker told BleepingComputer that BleepingComputer had actually attempted to warn the Internet Archive about the exposed token beforehand. Internet Archive never responded.
No sophisticated exploit. No zero-day. A configuration file that shouldn't have been public, containing credentials that should have been rotated, on a server that probably should have been decommissioned.
This is what Security Misconfiguration looks like in practice. And it's not rare — it's the second most common vulnerability in the world right now.
Why This Jumped to #2
When OWASP updated its Top 10 in 2025, Security Misconfiguration didn't rise because the problem got dramatically worse. It rose because software got dramatically more configurable.
Think about how much surface area a modern application has compared to 2015:
Cloud infrastructure (AWS, GCP, Azure) with hundreds of toggleable settings. Docker containers with their own permission models. Kubernetes clusters with role hierarchies. CI/CD pipelines with their own secrets stores. Third-party SaaS tools with OAuth connections. Feature flags. Environment variables. Infrastructure-as-code templates checked into version control.
Every one of those is a configuration decision. And unlike code vulnerabilities — where developers at least have the intent to write correct logic — misconfigurations are often introduced through copy-paste, through outdated tutorials, through "we'll tighten this later", or through simple human oversight.
OWASP found over 719,000 mapped CWEs in this category alone. It now affects more tested applications than any other category except Broken Access Control.
The 10 Misconfigurations I Actually Find During Assessments
These aren't theoretical. These are the patterns that come up repeatedly when we assess real production systems.
1. Secrets in source code. API keys, database passwords, and cloud credentials committed to Git repositories — sometimes public ones. We've written a full post on how this played out for one startup. GitHub reported over 39 million secrets leaked across repositories in 2024 alone.
2. Public S3 buckets. An S3 bucket set to public access during a debugging session or a rushed deployment. Never changed back. This pattern has caused more breaches than almost any other single misconfiguration — customer data, backups, internal documents, all freely accessible.
3. Overpermissioned IAM roles. An EC2 instance that has full admin access to the AWS account because someone took a shortcut during setup. If that instance is compromised, the attacker inherits every permission attached to it. We covered this in depth here.
4. Default credentials never changed. The database is still running on admin/admin. The management panel still accepts admin/password. The Wi-Fi router still uses the default from the box. Attackers have automated tools that try these against every exposed service they find.
5. Debug endpoints live in production. /debug, /actuator, /console, /.env. Developers enable these locally, they get deployed, and nobody notices. These endpoints frequently expose environment variables, application internals, dependency versions, and sometimes direct database access.
6. Verbose error messages. A stack trace that includes your framework version, your file paths, your database schema. Individually harmless. Together, a detailed map of your infrastructure for an attacker probing for weaknesses.
7. Misconfigured CORS. APIs that accept requests from any origin (Access-Control-Allow-Origin: *), including authenticated endpoints. This enables cross-site attacks where a malicious website can silently make API calls using a victim's session.
8. Unnecessary ports and services exposed. A Redis instance with no authentication, exposed to the public internet because someone opened port 6379 during testing. Redis has no built-in auth in older versions — it assumed it would only ever be accessed from trusted networks.
9. Cloud metadata endpoints accessible from application code. In AWS, the instance metadata endpoint at 169.254.169.254 can return temporary IAM credentials to anything running on that instance — including application code exploited via SSRF. This needs to be explicitly restricted.
10. Unauthenticated LLM API endpoints. This is the 2025 addition. Companies building AI-powered features are deploying LLM proxy endpoints without authentication — assuming they're internal. They're not always internal. An exposed LLM endpoint can be abused for LLMjacking, running up five-figure API bills before anyone notices.
The Dev/Staging/Prod Parity Problem
Here's the pattern that explains how many of these misconfigurations make it to production: they were intentional in development.
You open the S3 bucket publicly to test a feature quickly. You disable CORS restrictions so your local frontend can talk to the staging API. You set the database to accept all connections to avoid fiddling with local network config. You commit your .env file because it's easier than setting up secrets management locally.
None of these decisions are careless — they're pragmatic shortcuts for development speed. The problem is the gap between what's acceptable in development and what's safe in production. When those shortcuts don't get cleaned up before deployment — because no one has explicitly checked — they go live.
The most effective prevention is making the right configuration the default configuration. Deny-all by default. Private by default. Secrets pulled from a secrets manager, not from a .env file. These aren't complex engineering changes — they're structural habits that eliminate entire categories of risk.
Three Things You Can Do This Week
Run git-secrets or truffleHog against your repositories. These tools scan your commit history for credentials and API keys — including ones that were committed and then deleted (deletion from Git doesn't remove history). If you find something, rotate it immediately; assume it has been seen.
Audit your AWS S3 bucket permissions and IAM roles. AWS's own IAM Access Analyzer is free and will flag resources that are publicly accessible or overpermissioned. Run it. Look at the results. Our cloud security checklist covers the most critical items in detail.
Search your running application for exposed debug paths. Try appending /.env, /actuator/health, /actuator/env, /debug, and /console to your production domain. If any of them respond with anything other than a 404, you have an issue that needs addressing today.
How Kuboid Secure Layer Can Help
Misconfiguration is exactly what a well-scoped security assessment is designed to catch — because it requires someone who knows what they're looking for to actually look. Automated scanners find some of it. A security assessment finds the rest: the forgotten endpoint, the dev credential that made it to production, the IAM role that's three degrees more permissive than anyone realised.
Our cloud and infrastructure security reviews are specifically designed to surface the configuration gaps that your team is too close to see. Book a free consultation and we'll tell you honestly what we'd expect to find.
Have you ever found a misconfiguration in your own infrastructure — an open bucket, a committed key, a public endpoint you forgot about? Drop a comment below. This pattern is far more common than most teams want to admit, and sharing it helps everyone build better habits.
Kuboid Secure Layer provides cloud security assessments and web application penetration testing for growing businesses. Learn more at kuboid.in/services.
