OWASP Top 10

• The OWASP Top 10 (Open Web Application Security

Project) is a globally recognized list that outlines the
ten most critical web application security risks.
• It is a standard awareness document used by
developers, testers, security professionals, and organizations to
understand, identify, and mitigate common vulnerabilities in web applications.
• The list is based on data collected from real-world applications and security
assessments across thousands of organizations worldwide.
• It is updated periodically to reflect emerging threats and changes in technology.
• The OWASP Top 10 not only raises awareness about security risks but also
provides practical guidance on how to prevent them.
• Understanding and addressing these risks is essential to building secure software
and protecting user data from attackers.
A01: Broken Access Control
❖ Common Vulnerabilities

• Violation of least privilege or deny-by-default policy.

• Bypassing control checks by modifying URLs, internal app state, HTML page, or using
tools.
• Permitting viewing or editing someone else’s account by providing its unique
identifier (Insecure Direct Object References).
• Accessing APIs with missing controls for POST, PUT, and DELETE.
• Elevation of privilege- acting as a user without logged in or acting as admin when
logged in as user.
• Metadata manipulation to elevate privilege by tampering JWT or cookie or hidden
fields.
• CORS misconfiguration allows API access from unauthorized/untrusted origins.
• Force browsing to authenticated pages as unauthenticated user.

❖ How to Prevent

• Keep access control on the server side.

• Unless resource is public, deny by default.
• Use one central access control system throughout the app.
• Only let users access their own data, always verify ownership.
• Limit certain actions and code these rules in the backend.
• Hide sensitive files from users like .git files, backup files etc.
• Track and alert admin on failed access.
• Logout must destroy sessions from server also.
• Keep tokens like JWT short-lived.
 A02: Cryptographic Failures
❖ Common Vulnerabilities

• Data sent in clear text (over HTTP, FTP, SMTP).

• Old/weak encryption algorithms used (e.g., MD5, SHA1, DES).
• Default crypto keys used or keys stored in source code.
• No proper key rotation or management.
• Missing encryption enforcement (e.g., lack of HTTPS headers).
• Invalid or unverified TLS/SSL certificates.
• Weak or reused initialization vectors (IVs) in encryption.
• Using passwords directly as encryption keys (without key derivation).
• Use of deprecated hash functions.
• Use of deprecated padding method.

❖ How to Prevent

• Classify sensitive data – know what needs protection.

• Avoid storing sensitive data unless absolutely necessary.
• Encrypt sensitive data at rest and in transit.
• Use only strong and modern algorithms.
• Always use TLS (HTTPS) for secure communication and enforce it using HSTS headers.
• Disable caching of sensitive data in browsers and servers.
• Use unique, random IVs generated using secure random functions.
• Use authenticated encryption (AES-GCM).
• Generate and store keys securely – not in source code or config files.
• Use cryptographically secure random numbers.
• Test and verify encryption settings regularly for correctness.
A03: Injection
❖ Common Vulnerabilities

• User input is not validated, filtered, or sanitized, allowing malicious data to be

processed.
• Dynamic queries or non-parameterized calls include user input directly without
escaping.
• Directly adding user input in ORM/Object relational mappings can expose or
extract unauthorized sensitive records.
• Concatenation of input in SQL commands mixes instructions with malicious data.
• Multiple injection types – SQL, NoSQL, OS command, ORM, LDAP, EL and OGNL.
• Insecure coding practices across interpreters create identical injection risks.
• Lack of source code reviews leaves unsafe query construction unnoticed.
• Absence of automated testing on parameters, headers, URLs, cookies, JSON, SOAP,
and XML leaves hidden flaws.
• Missing SAST, DAST or IAST security testing in CI/CD means injection flaws reach
production.

❖ How to Prevent

• Use safe APIs or parameterized queries instead of string concatenation.

• Avoid concatenation in stored procedures.
• Apply strict server-side input validation.
• Escape special characters in dynamic queries.
• Block user input from controlling SQL structure (tables/columns).
• Conduct regular code reviews.
• Integrate SAST, DAST, IAST tools in CI/CD pipelines.
A04: Insecure Design
❖ Common Vulnerabilities

• Insecure design: missing or weak security controls from the start.

• Different from insecure implementation; even flawless code can’t fix bad design.
• Lack of business risk profiling → unclear requirements and poor choices.
• No definition of confidentiality, integrity, availability (CIA).
• Absence of threat modelling on data flows, access control, and attack risks.
• Use of outdated workflows (e.g., insecure password recovery Q&A).
• Weak business logic validation allowing unauthorized actions.
• No anti-bot protections → automated abuse (scalpers, fake signups).
• Poor multi-tenant segregation → data and access exposure.

❖ How to Prevent

• Integrate security into the SDLC with expert input early.

• Reuse secure design patterns and vetted components.
• Perform threat modelling for authentication, access control, and workflows.
• Define security requirements in user stories from the beginning.
• Apply plausibility checks across frontend, backend, and APIs.
• Use unit & integration tests to secure critical workflows.
• Create use-case & misuse-case scenarios to test real vs. malicious behavior.
• Segregate app, database, and network tiers by risk exposure.
• Ensure strict tenant isolation at every system layer.
• Set per-user or service resource limits to block bulk abuse or DDoS.
A05: Security Misconfiguration
❖ Common Vulnerabilities

• Weak security hardening or misconfigured cloud permissions.

• Unnecessary services, ports, accounts, or privileges enabled.
• Default accounts or passwords left unchanged.
• Error handling leaks sensitive details (e.g., stack traces).
• Security features disabled or misconfigured after upgrades.
• Insecure default settings in servers, frameworks, or databases.
• Missing or incorrectly set security headers (e.g., CSP, HSTS).
• Outdated or unpatched software components.
• No standardized process for environment security, causing inconsistencies.
• Overly permissive cloud storage (e.g., exposed S3 buckets).

❖ How to Prevent

• Apply a consistent hardening process across dev, QA, and production.

• Use unique credentials for each environment.
• Deploy a minimal setup by removing unused features, services, and sample apps.
• Regularly update and patch systems; review cloud permissions.
• Use segmentation, containerization, and strict ACLs for separation.
• Configure and enforce security headers (e.g., CSP, HSTS).
• Automate verification to detect misconfigurations continuously.
A06: Vulnerable and Outdated Components
❖ Common Vulnerabilities

• Not knowing the versions of all client-side and server-side components, including
nested dependencies.
• Using outdated, unsupported, or vulnerable software (OS, servers, DBMS, APIs,
runtimes, libraries).
• Not scanning regularly for vulnerabilities or subscribing to security bulletins.
• Delayed patching due to slow update cycles (monthly/quarterly), leaving long
exposure windows.
• Developers failing to test compatibility of updated or patched components.
• Insecure configuration of components (ties to Security Misconfiguration risk).
• Using unmaintained components or libraries with no security patch support.

❖ How to Prevent

• Establish a patch management process for timely updates.

• Remove unused dependencies, features, files, and documentation.
• Maintain a continuous inventory of all components (frameworks, libraries,
dependencies).
• Use tools like OWASP Dependency Check, retire.js, or SCA tools to detect
vulnerable components.
• Only download components from official, secure sources; prefer signed packages.
• Watch for unmaintained libraries and replace or mitigate them.
• If patching isn’t possible, apply virtual patches or monitoring controls.
• Maintain an ongoing plan for monitoring, triaging, and updating throughout the
app’s lifecycle.
A07: Identification & Authentication Failures
❖ Common Vulnerabilities

• Allows automated attacks like credential stuffing with stolen username/password

lists.
• Permits brute force attacks without detection or blocking.
• Accepts default, weak, or well-known passwords (e.g., admin/admin, Password1).
• Uses insecure credential recovery methods (e.g., knowledge-based Q&A).
• Stores passwords in plain text, weakly hashed, or improperly encrypted formats.
• Lacks or has ineffective multi-factor authentication (MFA).
• Exposes session IDs in the URL, making them easy to steal.
• Reuses session identifiers after successful login.
• Fails to invalidate sessions or tokens (SSO tokens, session IDs) after logout or
inactivity.

❖ How to Prevent

• Enforce multi-factor authentication to stop credential stuffing and brute force

attacks.
• Never deploy with default credentials, especially for admin accounts.
• Check new passwords against common weak password lists.
• Follow NIST 800-63b password guidelines (length, complexity, rotation).
• Harden registration, login, and recovery flows against account enumeration with
uniform responses.
• Limit or delay repeated login attempts and log suspicious activity for alerts.
• Use a secure session manager: Generate strong random session IDs after login.
• Do not expose session IDs in the URL.
• Invalidate sessions on logout, idle timeout, and absolute timeout.
A08: Software & Data Integrity Failures
❖ Common Vulnerabilities

• Relying on plugins, libraries, or modules from untrusted sources, repositories, or

CDNs.
• Insecure CI/CD pipelines allowing unauthorized access, malicious code, or system
compromise.
• Auto-update features that download and apply updates without verifying integrity.
• Attackers uploading malicious updates that get distributed to all installations.
• Using serialization/deserialization where attackers can see/modify objects or data
(leading to insecure deserialization).

❖ How to Prevent

• Use digital signatures or integrity checks to verify software/data sources.

• Consume libraries/dependencies only from trusted repositories (e.g., npm, Maven)
or maintain an internal vetted repo.
• Use supply chain security tools (e.g., OWASP Dependency Check, CycloneDX) to
detect vulnerabilities in components.
• Enforce a code/configuration review process to catch malicious changes.
• Secure the CI/CD pipeline with proper segregation, configuration, and access
controls.
• Avoid sending unsigned or unencrypted serialized data to untrusted clients; use
integrity checks or signatures.
A09: Security Logging & Monitoring Failures
❖ Common Vulnerabilities

• Missing logs for critical events (logins, failed logins, high-value transactions).
• Warnings/errors produce no or vague log messages.
• Application/API logs not monitored for suspicious activity.
• Logs stored only locally, no central correlation.
• No alerting thresholds or escalation processes.
• Penetration tests/DAST scans (e.g., OWASP ZAP) not triggering alerts.
• System cannot detect or respond to attacks in real-time.
• Information leakage via logs or alerts exposed to users/attackers.
• Log injection attacks possible if log data not properly encoded.

❖ How to Prevent

• Log all login, access control, and input validation failures with enough context for
forensic analysis.
• Standardize log format for log management system compatibility.
• Encode log data to prevent log injection.
• Protect audit trails of high-value transactions with integrity controls.
• Implement effective monitoring & alerting for suspicious activity.
• Adopt a formal incident response & recovery plan (e.g., NIST 800-61r2).
• Use security frameworks & tools (e.g., OWASP ModSecurity CRS, ELK stack) for
correlation, dashboards, and alerting.
A10: Server-Side Request Forgery (SSRF)

❖ Common Vulnerabilities

• Application fetches remote resources without validating user-supplied URLs.

• Attackers can force the server to send crafted requests to internal/external
systems.
• SSRF bypasses protections like firewalls, VPNs, and ACLs by pivoting through the
server.
• Lack of network segmentation allows attackers to port-scan internal servers.
• Exposing sensitive files/services.
• Access to cloud metadata endpoints can leak credentials.
• Blind SSRF allows attackers to map networks even without direct responses.
• Failure to control HTTP redirects leads to further exploitation.
• DNS rebinding and TOCTOU race conditions bypass weak validation.
• Reliance on deny lists/regex filters, which are easily bypassed by attackers.
• Running security-critical services (e.g., OpenID, admin panels) on exposed front
systems.
A10: Server-Side Request Forgery (SSRF)
❖ How to Prevent

➢ From Network Layer

• Segment resource-fetching functionality into separate networks.
• Enforce “deny by default” firewall policies; allow only essential outbound
traffic.
• Maintain ownership & lifecycle for firewall rules per application.
• Log all accepted and blocked flows at firewalls for monitoring.

➢ From Application Layer

• Validate and sanitize all user-supplied URLs.
• Enforce positive allow list for URL schema, host, port, and destination.
• Block requests to private/internal IP ranges.
• Disable HTTP redirections for untrusted requests.
• Use strict URL parsing libraries to avoid DNS rebinding and TOCTOU
attacks.
• Never rely on deny lists/regex (attackers can bypass them).
• Do not send raw responses from remote fetches back to clients.

➢ Additional Security Measures

• Avoid running security-sensitive services on front-facing systems.
• Control local traffic (localhost) to prevent abuse.
• For high-security frontends, enforce network encryption (VPNs) on
isolated systems.
• Monitor outgoing traffic for suspicious activity (e.g., SSRF scans).