OWASP Top 10: Authentication, Crypto Failures and Misconfiguration

A film club sells tickets through a small site it built over a weekend. Three months later a member reports that she received a password-reset link which still worked after she had used it twice. Someone else points out that the staging site, with real members in its database, loads over plain HTTP and prints a full stack trace on errors. Three separate flaws, one shared cause: the defaults were never reviewed. Each belongs to a theme the OWASP Top 10 (current edition) calls out, and none of them needs a clever attacker.

Authentication failures

This theme covers everything that lets someone be treated as a user they are not. The classic causes are accepting weak or breached passwords, no protection against automated guessing, session identifiers that are predictable or never expire, reset and recovery flows that are weaker than the login, and exposing session ids in URLs. Fixes line up with each cause:

• Throttle login attempts with growing delays, and alert on bursts of failures.
• Offer multi-factor authentication and require it for admin accounts.
• Check new passwords against known-breached lists and enforce minimum length rather than composition rules.
• Issue a fresh session id after login, expire sessions on logout and after inactivity, and invalidate them on password change.
• Make reset tokens random, single-use, short-lived and tied to the account, and send the same response whether or not the email exists.

Cookies carry sessions, so their flags matter. In HTTP response form, a well-configured session cookie looks like this. The HttpOnly flag keeps scripts from reading it, Secure restricts it to HTTPS, and SameSite limits cross-site sending, which reduces cross-site request forgery.

Set-Cookie: session=<random-id>; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600

If your app uses token-based sessions rather than server-side ones, the same ideas apply to signing, expiry and storage; see JWT authentication for the specifics.

Cryptographic failures

The theme used to be described as "sensitive data exposure", and the shift in wording is instructive: the root cause is usually weak or missing cryptography, not the exposure itself. Typical forms are data sent over plain HTTP, obsolete algorithms (MD5 or SHA-1 for passwords or signatures), hard-coded keys in source, passwords stored unhashed or with fast hashes, predictable random numbers for tokens, and storing data that was never needed.

The random-number point is easy to get wrong in code. General-purpose generators are designed for speed and statistical spread, and their output can be reproduced from a seed. For anything an attacker must not guess (reset tokens, session ids, invite codes) use the operating system's cryptographic generator.

import random
import secrets

# random is a Mersenne Twister: fine for shuffling a playlist, wrong for secrets.
# secrets draws from the operating system's cryptographic generator.
reset_token = secrets.token_urlsafe(32)
print("token length:", len(reset_token))
print("two tokens differ:", secrets.token_urlsafe(32) != secrets.token_urlsafe(32))

# Predictability demo: seed the plain generator twice and get the same "random" value.
random.seed(1234)
first = random.getrandbits(32)
random.seed(1234)
second = random.getrandbits(32)
print("same seed, same output:", first == second)

token length: 43
two tokens differ: True
same seed, same output: True

A sensible baseline: HTTPS everywhere with HSTS, a modern authenticated encryption mode when you must encrypt data at rest, passwords hashed with a slow salted algorithm (covered in passwords, MFA and hashing), keys kept in a secrets manager or environment-specific store and never in a repository, and a rotation plan. Prefer vetted libraries over writing your own cryptography, and delete data you do not need, since data you never stored cannot leak.

Security misconfiguration

Most software ships with settings aimed at making things easy for developers: sample accounts, verbose errors, open cloud storage, directory listings, default admin pages. Misconfiguration is leaving those in place, or drifting out of line between environments. It is the least glamorous theme and one of the most reliable sources of real incidents, because it needs no bug in your code.

Headers are a quick, visible place to start. This script audits a sample response for missing protective headers and for version information that tells outsiders exactly which software to look up flaws for.

EXPECTED = {
    "strict-transport-security": "force browsers to use HTTPS",
    "content-security-policy": "limit where scripts and frames can load from",
    "x-content-type-options": "stop MIME sniffing (should be 'nosniff')",
    "referrer-policy": "limit URLs leaked to other sites",
}
LEAKY = ("server", "x-powered-by")

def audit(response_headers: dict[str, str]) -> list[str]:
    seen = {k.lower(): v for k, v in response_headers.items()}
    findings = []
    for name, why in EXPECTED.items():
        if name not in seen:
            findings.append(f"missing {name}: {why}")
    for name in LEAKY:
        if name in seen and any(ch.isdigit() for ch in seen[name]):
            findings.append(f"{name} reveals a version: {seen[name]}")
    return findings

sample = {
    "Content-Type": "text/html",
    "Server": "Apache/2.4.41",
    "X-Powered-By": "PHP/7.4.3",
    "X-Content-Type-Options": "nosniff",
}
for finding in audit(sample):
    print(finding)

missing strict-transport-security: force browsers to use HTTPS
missing content-security-policy: limit where scripts and frames can load from
missing referrer-policy: limit URLs leaked to other sites
server reveals a version: Apache/2.4.41
x-powered-by reveals a version: PHP/7.4.3

Common mistakes

• Debug mode on in production. Symptom: an error page showing stack traces, file paths and sometimes connection strings. Fix: generic error pages to users, details to logs only.
• Real data in staging with weaker controls. Symptom: a staging database leaks real members. Fix: synthetic or masked data, and the same access rules as production.
• Secrets committed to the repository. Symptom: a key found in git history months later, still valid. Fix: rotate it first, then move secrets to a manager and add secret scanning.
• Default credentials on admin consoles or databases. Symptom: an internet-facing panel that accepts the vendor default. Fix: change at install, restrict by network, disable what you do not use.
• Reusing a reset token after use. Symptom: an old email link still logs someone in. Fix: single-use, expiring tokens, invalidated on use.

How this shows up in real projects and interviews

In interviews these themes appear as design questions: "how would you build password reset?" and "how do you manage secrets for a service?" Real teams meet them as findings in a penetration test or a cloud security scanner, and the fixes are mostly configuration and process, which is why they get fixed late. A habit worth building is keeping environment configuration in version control (without the secrets), so drift between staging and production can be seen in a diff. If you work on pipelines, CI/CD is the natural place to run secret scanning and dependency checks.