Web Security Fundamentals: OWASP Top 10 Overview

Last updated: Apr 13, 2025

Table of Contents

1. Introduction: Why Web Security Matters

In today’s interconnected world, web applications handle vast amounts of sensitive data and perform critical
functions. From e-commerce sites processing payments to internal tools managing company data, the security of
these applications is paramount. A security breach can lead to data theft, financial loss, reputational
damage, and legal consequences.

As developers, understanding common web security vulnerabilities is the first step towards building more
secure applications. Fortunately, organizations like OWASP provide valuable resources to help identify and
mitigate these risks.

2. What is OWASP and the Top 10?

The Open Web Application Security Project (OWASP) is a non-profit foundation dedicated to
improving software security. It’s a community-led open-source project that produces articles, methodologies,
documentation, tools, and technologies in the field of web application security.

One of OWASP’s most well-known projects is the OWASP Top 10. This is a standard awareness
document representing a broad consensus about the most critical security risks to web applications. It’s
updated periodically (the latest version as of writing is 2021) based on data analysis and community surveys,
highlighting the vulnerabilities developers should prioritize addressing.

The Top 10 list is not exhaustive, but it provides an excellent starting point for understanding common
threats and implementing basic security hygiene.

3. OWASP Top 10 - 2021 Edition (Overview)

Here’s a brief overview of each risk category in the 2021 OWASP Top 10, along with simple examples and basic
mitigation ideas.

A01: Broken Access Control

Description: Failures related to enforcing restrictions on what authenticated users are
allowed to do. Users might gain access to unauthorized functionality or data.

Example: A user changing the ID parameter in a URL (/user/123/profile to
/user/456/profile) and being able to view or edit another user’s profile without proper checks.

Mitigation: Implement access control checks on the server-side for every request. Verify
user permissions based on their role or ownership of the requested resource. Deny access by default.

A02: Cryptographic Failures

Description: Issues related to cryptography (or lack thereof), often leading to exposure of
sensitive data. This includes using weak algorithms, improper key management, or transmitting sensitive data
in clear text.

Example: Storing user passwords as plain text or using easily reversible hashing (like MD5
without salting) instead of strong, salted hashing algorithms (like Argon2, bcrypt). Transmitting sensitive
data over HTTP instead of HTTPS.

Mitigation: Use strong, modern cryptographic algorithms and protocols. Always transmit
sensitive data over TLS/HTTPS. Use strong password hashing with unique salts per user. Encrypt sensitive data
at rest. Securely manage cryptographic keys.

A03: Injection

Description: Flaws where untrusted user input is sent to an interpreter (like SQL, NoSQL, OS
command, LDAP) as part of a command or query, allowing the attacker to execute unintended commands or access
data without authorization.

Example (SQL Injection): A query constructed like
"SELECT * FROM users WHERE id = '" + userId + "';" where userId comes directly from
user input. An attacker could input ' OR '1'='1, resulting in the query
SELECT * FROM users WHERE id = '' OR '1'='1';, potentially returning all users.

Mitigation: Use safe APIs that avoid interpreters entirely (e.g., parameterized queries,
prepared statements for SQL). Perform server-side input validation and sanitization. Escape special
characters.

A04: Insecure Design

Description: A new category focusing on risks related to design and architectural flaws. It
emphasizes the need for threat modeling and integrating security throughout the software development
lifecycle, rather than treating security as an afterthought.

Example: Designing an e-commerce checkout flow that doesn’t adequately protect against race
conditions when applying discounts, potentially allowing multiple discounts to be applied unfairly.

Mitigation: Use threat modeling during design phases. Implement secure design patterns.
Write robust unit and integration tests covering security scenarios. Ensure secure defaults.

A05: Security Misconfiguration

Description: Issues arising from incorrectly configured security controls or insecure
default settings.

Example: Leaving default administrative accounts/passwords enabled. Exposing sensitive error
messages or stack traces to users. Not applying security patches promptly. Unnecessarily open cloud storage
permissions. Missing appropriate security headers (like Content Security Policy).

Mitigation: Harden configurations; disable unused features/services. Review and customize
default settings. Implement automated processes for patching and configuration management. Use security
headers.

A06: Vulnerable and Outdated Components

Description: Using software components (libraries, frameworks, OS) with known security
vulnerabilities.

Example: Using an old version of a JavaScript library (e.g., jQuery, Lodash) or a backend
framework (e.g., Struts, Spring) with a published critical vulnerability that allows remote code execution.

Mitigation: Regularly scan dependencies for known vulnerabilities (using tools like OWASP
Dependency-Check, npm audit, Snyk, Dependabot). Keep components updated to patched versions. Remove unused
dependencies.

A07: Identification and Authentication Failures

Description: Weaknesses in user identity management, authentication, and session management.

Example: Allowing weak passwords. Not implementing multi-factor authentication (MFA).
Improper session invalidation after logout or password change. Exposing session IDs in URLs. Permitting
credential stuffing or brute-force attacks without rate limiting.

Mitigation: Implement strong password policies. Enforce MFA. Secure session management (use
secure cookies, regenerate session IDs on login, implement timeouts). Protect against automated attacks (rate
limiting, captchas).

A08: Software and Data Integrity Failures

Description: Failures related to code and infrastructure integrity, often related to
insecure CI/CD pipelines or relying on plugins/libraries from untrusted sources. Also includes insecure
deserialization.

Example: A CI/CD pipeline pulling dependencies over insecure channels or without verifying
their integrity. An application deserializing untrusted user input without validation, potentially leading to
remote code execution.

Mitigation: Use secure CI/CD practices (verify dependencies, scan artifacts). Ensure digital
signatures are used for software updates. Avoid deserializing untrusted data or use safe serialization
alternatives.

A09: Security Logging and Monitoring Failures

Description: Insufficient logging, monitoring, and alerting, making it difficult to detect
and respond to security incidents.

Example: Not logging critical events like logins, failed logins, or access control failures.
Logs not being centrally collected or monitored. Lack of alerting for suspicious activities.

Mitigation: Log significant security events. Ensure logs are detailed enough for analysis,
protected from tampering, and monitored. Implement effective alerting for potential incidents.

A10: Server-Side Request Forgery (SSRF)

Description: Vulnerabilities where a web application fetches a remote resource based on a
user-supplied URL without proper validation, allowing an attacker to coerce the application into sending
crafted requests to unexpected destinations (e.g., internal network services, cloud metadata endpoints).

Example: An application feature that fetches an image preview based on a URL provided by the
user (/getImage?url=USER_SUPPLIED_URL). An attacker provides an internal URL like
http://169.254.169.254/latest/meta-data/ (AWS metadata service) or
http://localhost:8080/admin.

Mitigation: Validate user-supplied URLs against a strict allow-list of permitted schemes,
hosts, and ports. Disable unused URL schemes on the server. Implement network segmentation and firewall rules
to prevent the server from accessing internal resources unnecessarily.

4. General Mitigation Principles

While specific mitigations vary, several principles apply broadly:

  • Validate Input:Treat all input (from users, APIs, files) as untrusted. Validate,
    sanitize, and/or escape data appropriately based on context.

  • Principle of Least Privilege:Grant users and processes only the minimum permissions
    necessary to perform their tasks.

  • Defense in Depth:Implement multiple layers of security controls.

  • Secure Defaults:Configure systems and frameworks securely by default.

  • Keep Systems Updated:Regularly patch OS, frameworks, and libraries.

  • Use Secure Frameworks/Libraries:Leverage built-in security features of modern
    frameworks.

  • Implement Logging & Monitoring:Detect and respond to potential incidents.

  • Security Testing:Perform regular security audits and penetration testing.

5. Conclusion: Continuous Vigilance

The OWASP Top 10 provides an invaluable baseline for understanding and addressing the most critical web
application security risks. It highlights that security is not a one-time fix but an ongoing process requiring
attention throughout the design, development, and deployment lifecycle.

By familiarizing yourself with these common vulnerabilities and adopting secure coding practices, input
validation, proper configuration, and dependency management, you can significantly improve the security
posture of your web applications.

Additional Resources

Related Articles on InfoBytes.guru

External Resources