Skip to content
Adrythm
Custom software

Security misconfiguration

hardening / default credentials / baseline configuration / OWASP A02

In short

Security misconfiguration is software set up incorrectly rather than written incorrectly. OWASP ranks it second in its 2025 Top 10 and lists the usual causes: unnecessary features enabled, default accounts unchanged, and errors that show users a stack trace. The fix is a baseline somebody owns.

The definition is refreshingly plain. Security misconfiguration is when a system, application, or cloud service is set up incorrectly from a security perspective, creating vulnerabilities. Nobody wrote a bad line of code. Somebody left a setting where it was.

OWASP then lists what that looks like, and the list is recognizable to anyone who has inherited a system. Unnecessary features are enabled or installed, meaning unnecessary ports, services, pages, accounts, testing frameworks or privileges. Default accounts and their passwords are still enabled and unchanged. Error handling reveals stack traces or other overly informative error messages to users. And the sentence that names the real cause: without a concerted, repeatable application security configuration hardening process, systems are at a higher risk.

The prevention list reads like an operations manual rather than a security one. A minimal platform without any unnecessary features, components, documentation, or samples. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. And a line worth quoting back to anyone who says the checks are automated: if these verifications are not automated, they should be manually verified annually at a minimum.

The standards side supplies the noun for what is missing. A baseline configuration is a set of specifications for a system, or configuration item within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. It is used as a basis for future builds, releases, and changes. That is the difference between settings that are correct today and settings that stay correct.

In practice

This is the flaw most likely to arrive with a system you did not build. A site moved to new hosting, a plugin installed for one campaign, a test environment that was never taken down. None of it is a coding decision, which is why it falls between the developer who finished and the person who now runs it.

Not the same as

A bug
The software works as written. The question is which options were left on and which defaults were left alone.
Patching
Keeping versions current is a separate discipline. A fully patched system with directory listing enabled and a default admin password is still exposed.

Why it matters to you

Nobody is assigned to settings. Code has an author and a review, hosting has an invoice, and configuration sits between them with no owner, which is exactly why OWASP finds it near the top every time. The useful move is not a security project. It is naming who holds the baseline and what happens when somebody changes it.

What to ask or check

  1. 01Is there a written baseline for how our systems are configured, and who approves changes to it?
  2. 02Are the test and production environments configured the same way, with different credentials?
  3. 03What does a visitor see when something breaks, and does it include a stack trace?

What people get wrong

That this is a developer problem. The prevention list is about environments, defaults, permissions and error handling, which are operations decisions taken long after the code was written.

Red flags

  • A test or staging environment reachable from the internet.
  • Nobody able to say which accounts still have their original passwords.
  • An error page that shows a file path or a stack trace to a visitor.

Who owns it

Whoever runs the system rather than whoever built it, which is why it needs a name attached before the handover rather than after.

Where you will see it

In an error page, in a directory listing, and in the admin account nobody has logged into since the site launched.

Broken access control

Broken access control is an application letting someone see or do something their account should not. OWASP ranks it first in its 2025 Top 10 and reports that 100 percent of applications tested had some form of it. The rule that matters: a check enforced only in the browser is not a check.

Multi-factor authentication

Multi-factor authentication means proving who you are with two different kinds of evidence. NIST treats it as a level rather than a switch: at AAL2 two distinct factors are required and the application must offer a phishing-resistant option. Vendor lists run from text messages to passkeys, all labeled MFA.

Definition of done

A definition of done is the written list of conditions every piece of work must meet before anyone calls it finished. The Scrum Guide treats it as a gate: work that misses it cannot be released or even shown at the review. Agile Alliance warns that an unwritten one loses most of its value.

Velocity

Velocity is the total of the estimates a team finished in one iteration. Agile Alliance is blunt about what it is not: a measurement made after the fact, not a budget or a forecast, with no meaningful comparison between teams and no such thing as an individual velocity.

Sprint

A sprint is a fixed length block of development work, one month or less in the Scrum Guide and usually one to four weeks in practice. The fixed length is the point: it is what makes a completion estimate possible, and it decides what can be changed once the block has started.

User story

A user story is a small slice of work written from the user's point of view, usually to a role, feature, reason template. The Agile Alliance defines it and offers INVEST as the quality test. The Scrum Guide, the framework most teams name, does not use the phrase at all.

Want this explained against your own numbers?

Twenty minutes, a straight answer, and no follow-up sequence if you decide not to work with us.