OWASP Top 10:
Critical Web Application Security Risks

What it means

Broken Access Control happens when an application fails to properly check whether a user is allowed to perform a specific action or access a specific resource. In many cases, the application shows the correct UI but doesn't enforce the rule on the server.

Why it matters

It is currently ranked #1 because unauthorized access can expose customer data, allow account takeover, and enable actions on behalf of other users. The impact is often severe and directly affects privacy and trust.

Common causes

• Missing server-side authorization checks
• Relying on UI hiding instead of access rules
• Insecure direct object references (IDOR)
• Weak or inconsistent role-based access control

What website owners can do

• Ask your developer to confirm that every privileged action is checked on the server
• Log out and back in as a lower-privilege user and try to reach admin pages
• Review third-party plugins for anything that grants elevated access

What developers can check

• Enforce access control in a centralized place that can't be bypassed
• Deny by default unless a resource is explicitly public
• Use ownership checks on every resource access, not just the UI

What it means

This category covers failures related to cryptography — including missing HTTPS, weak ciphers, outdated algorithms, and sensitive data stored in plaintext. It was formerly called "Sensitive Data Exposure."

Why it matters

Data leaks are expensive and reputation-damaging. Regulations like GDPR and India's DPDP Act also require reasonable protection of personal data.

Common causes

• No HTTPS or mixed content on HTTPS pages
• Using MD5, SHA-1, or legacy TLS versions
• Storing passwords or tokens in plaintext
• Poor key management practices

What website owners can do

• Ensure HTTPS is enabled and enforced site-wide
• Check your SSL/TLS configuration with an SSL checker
• Ask your developer what algorithms are used for password hashing

What developers can check

• Use modern algorithms (AES-256, Argon2, bcrypt) for sensitive data
• Enforce HSTS to prevent downgrade attacks
• Rotate encryption keys periodically

What it means

Injection happens when untrusted data is passed to an interpreter (like a database or shell) and executed as code. Common forms include SQL injection, NoSQL injection, OS command injection, and LDAP injection.

Why it matters

Injection can lead to full database disclosure, data tampering, and sometimes remote code execution. It has been a top risk for over a decade.

Common causes

• String concatenation to build queries
• Missing or weak input validation
• Passing user input directly to system shells
• Trusting client-side validation

What website owners can do

• Ensure your developer uses parameterized queries everywhere
• Keep your CMS and plugins up to date
• Avoid custom SQL built from user input

What developers can check

• Use prepared statements with bound parameters
• Apply server-side allowlists for expected input formats
• Escape output contextually (HTML, URL, JS)

What it means

Insecure Design is about flaws that come from the way an application was planned — not from a coding mistake. If security was not part of the design, no amount of code-level fixes can fully compensate.

Why it matters

Design flaws are usually deeply rooted and expensive to fix later. They often expose multiple features at once.

Common causes

• No threat modeling during planning
• Rushing features without security review
• Assuming "the framework handles it"

What website owners can do

• Ask for threat modeling before new features are built
• Request security acceptance criteria in every project
• Ensure there is a defined process for security reviews

What developers can check

• Document trust boundaries and data flows
• Design fail-safe defaults and separation of concerns
• Include abuse-case scenarios in design reviews

What it means

Security Misconfiguration covers everything from default admin credentials to missing security headers, unnecessary features, and detailed error pages that reveal internal details.

Why it matters

Misconfigurations are one of the easiest issues for attackers to find, and one of the easiest for defenders to fix — making them a high-priority category.

Common causes

• Default credentials left in place
• Missing security headers (HSTS, CSP, X-Frame-Options)
• Directory listing enabled
• Verbose error messages in production

What website owners can do

• Change all default credentials on install
• Disable directory listing and debug mode in production
• Review security headers with a headers checker

What developers can check

• Build a hardened baseline configuration
• Automate configuration checks in CI/CD
• Keep separate, minimal production environments

What it means

Modern websites use many libraries, plugins, and frameworks. If any of them have known security vulnerabilities, your whole website inherits that risk.

Why it matters

Known vulnerabilities are easy for attackers to exploit at scale. Regular updating is one of the highest-value security habits you can build.

Common causes

• Not updating CMS, plugins, or themes
• Not monitoring CVE databases for used libraries
• Relying on abandoned or unsupported packages

What website owners can do

• Enable automatic updates where safe
• Remove plugins and themes you no longer use
• Choose vendors with a strong security track record

What developers can check

• Run dependency scanners (e.g., OWASP Dependency-Check)
• Pin known-good versions and rotate them deliberately
• Track security advisories for your stack

What it means

This category covers weaknesses in how users are identified and authenticated — weak password policies, missing multi-factor authentication, session fixation, and unsafe "remember me" tokens.

Why it matters

Account takeover is often the fastest way for an attacker to reach sensitive data and privileged features.

Common causes

• No rate limiting on login attempts
• Weak password policies
• Sessions that don't rotate on login
• Credentials sent in URLs

What website owners can do

• Turn on multi-factor authentication for admin accounts
• Use a password manager and unique passwords everywhere
• Log out inactive sessions regularly

What developers can check

• Enforce rate limiting and account lockout on authentication
• Rotate session IDs after login and privilege change
• Store passwords with a modern hash (bcrypt, Argon2)

What it means

This category is about code and infrastructure that doesn't verify the integrity of what it depends on — auto-updates from untrusted sources, insecure CI/CD pipelines, or unsafe deserialization of data.

Why it matters

Integrity failures can introduce backdoors, allow attackers to inject data, or compromise entire deployment pipelines at once.

Common causes

• Unsigned updates or packages
• Insecure deserialization of user data
• Weak supply chain controls

What website owners can do

• Install updates from official sources only
• Avoid unofficial "nulled" plugins or themes
• Keep backups so you can roll back quickly

What developers can check

• Sign and verify release artifacts
• Avoid untrusted deserialization
• Secure CI/CD pipelines with least privilege

What it means

Even a well-built application needs to detect attacks and respond quickly. If logins, errors, and security events aren't logged and monitored, breaches can go unnoticed for months.

Why it matters

Detection is what turns an incident into a manageable event. Without monitoring, you often learn about a breach from a third party — not your own systems.

Common causes

• No logging of authentication and authorization events
• Logs stored only locally with no review
• No alerting for suspicious patterns

What website owners can do

• Confirm your host or CMS logs authentication events
• Enable email or dashboard alerts for suspicious logins
• Retain logs long enough to investigate incidents

What developers can check

• Log with structured context (who, what, when, where)
• Do not log credentials or sensitive tokens
• Ship logs to a centralized, tamper-resistant store

What it means

SSRF occurs when an application fetches a URL on behalf of a user without properly validating where that URL points. Attackers can use this to reach internal services that should not be accessible from the internet.

Why it matters

SSRF is often used to pivot into cloud metadata services and internal networks, making it a high-impact risk in modern architectures.

Common causes

• Fetching user-supplied URLs without validation
• Not blocking internal IP ranges or metadata endpoints
• Trusting headers like Host or X-Forwarded-For

What website owners can do

• Ask whether any feature fetches external URLs on your behalf
• Ensure cloud metadata access is restricted
• Restrict outbound network access where possible

What developers can check

• Use allowlists for outbound requests
• Block private IP ranges and cloud metadata endpoints
• Disable unnecessary URL fetching features