OWASP: Web Application Security Reference

Posted by

 

Securing modern applications is an increasingly complex challenge. OWASP, one of the world's leading organizations dedicated to software security, offers open-source resources, standards, and tools to help developers and professionals build more secure applications. In this guide, we'll delve into what OWASP is, analyze the OWASP Top 10 in detail, and discover the best projects for learning about cybersecurity in a practical way.

🔗 Do you like Techelopment? Check out the site for all the details!


What is OWASP

OWASP (Open Web Application Security Project) is a non-profit foundation and a global community of professionals (developers, security engineers, researchers, pentesters) that produces open-source resources to improve application security. The primary goal is to make application security accessible and practicable: free guidelines, tools, checklists, training, and educational projects that can be used by individual developers, businesses, and governments.


Key Features

  • Community-driven: Content is based on open contributions and community reviews.
  • Open source: Documents, tools, and projects are freely accessible and reusable.
  • Pragmatic: Focus on real-world problems, practical examples, testing tools, and concrete mitigations.
  • Industrial relevance: Many organizations use the OWASP guidelines as an operational reference for security assessments and requirements.

OWASP Top 10

The OWASP Top 10 is a list of the most critical risk categories for web applications. It's not exhaustive, but it's an excellent starting point for understanding where to focus controls and testing. Each item below contains: what it is, practical examples, how to detect/test it, and recommended mitigations.

1) Broken Access Control (Missing or Incorrect Access Controls)

What it is: Insufficient permissions or poorly implemented access controls that allow unauthorized actions (viewing, modifying, deleting other people's data, privilege escalation).

Examples: Changing user_id in the URL to access another user's data; API endpoint not verifying role before sensitive operations.

How to test: Try ID/parameter manipulation, call APIs with different privilege levels, test unpublicized endpoints.

Mitigations: 

  • Verify authorization on the server for every sensitive operation (not just on the client)
  • Principle of least privilege (minimum roles)
  • Implement centralized RBAC/ABAC policies
  • Avoid security based solely on "secrets" in the client (e.g., hidden fields)

2) Cryptographic Failures (Errors in encryption / protection of sensitive data)

What it is: Incorrect or insufficient use of cryptography, exposure of sensitive data in plain text (passwords, cards, tokens).

Examples: Store passwords in clear text, use weak algorithms (MD5), and don't use TLS for sensitive transfers.

How to test: Search for sensitive, unencrypted data in DBs, logs, or API responses; verify TLS configuration; Check hashing algorithms.

Mitigations:

  • Securely hashed password store (bcrypt/Argon2/PBKDF2) + unique salt
  • Transit: TLS 1.2/1.3 with secure configuration
  • Data-at-rest encryption if needed (field-level encryption)
  • Secure key management (KMS, rotation, restricted access)

Example (password hashing — Python pseudocode)

from passlib.hash import bcrypt
hashed = bcrypt.hash("SuperPassword123")
bcrypt.verify("SuperPassword123", hashed)

3) Injection

What it is: Inserting malicious data into commands or queries that the server executes (SQL, NoSQL, OS, LDAP, etc.), possibly executing unexpected commands.

Examples: SQL injection (' OR 1=1 --), concatenating input to the shell.

How to test: Fuzzing and malformed input, using payloads known for SQLi/command injection, automatic scanners.

Mitigations:

  • Use parameterized queries / prepared statements (never concatenate strings).
  • Context-centric validation and sanitization.
  • DB privilege minimization.
  • Whitelisting for structured input (e.g., ID numeric).

Example (Prevent SQLi in Python with parameterized query)

cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

4) Insecure Design

What it is: Lack of security considerations in the design/architecture phase: lack of threat modeling, insufficient controls, and risky design decisions.

Examples: Internal services exposed publicly, no separation of responsibilities, no rate limits for sensitive operations.

How to test: Architectural review, threat modeling, data flow analysis, dependency review, and trust model.

Mitigations:

  • Threat modeling (STRIDE, PASTA) during design
  • Security by design: fail-secure defaults, defense in depth
  • Architectural review and security policies integrated into the development cycle


5) Security Misconfiguration

What it is: Insecure configurations in the server, framework, or services (debug mode enabled, directory listing, default creds).

Examples: Missing security headers, mistakenly public S3 buckets.

How to test: Configuration scanner, HTTP header inspection, default password verification, file and directory checks.

Mitigations:

  • Hardening configurations (security principles for web servers, databases, frameworks)
  • Removing unused features, disabling debugging in production
  • Automating configuration management (IaC with security checks)

Useful headers to add: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security.


6) Vulnerable and Outdated Components

What is it: Using libraries, frameworks, or images containers with known vulnerabilities that allow compromise.

Examples: dependencies with known CVEs that are not updated; Container images with vulnerable software.

How to test: dependency scanning (SCA), SBOM, version verification, and CVE.

Mitigations: 

  • Regular dependency updates and patching
  • Use SCA tools (dependency-check, OWASP Dependency-Track)
  • CVE monitoring and patch management policies
  • Limit surfaces exposed by external components


7) Identification and Authentication Failures

What it is: Weak or poorly implemented authentication mechanisms that allow account takeover or bypass.

Examples: Weak session management (session fixation), insecure password reset, lack of MFA for sensitive operations.

How to test: Test brute force logins, session fixation attempts, analyze password and token reset flows.

Mitigations:

  • Implement MFA/2FA for sensitive operations
  • Use secure session tokens, with expiration and revocation
  • Limit login attempts (rate limiting), account lockout, or challenges
  • Protect password reset endpoints with verification and limits


8) Software and Data Integrity Failures

What it is: Lack of code or data integrity checks (e.g., unsigned updates, lack of control over CI/CD artifacts).

Examples: CI pipeline that allows unsigned artifacts or packages from unverified repositories; Use of unsigned plugins.

How to test: Verify digital signatures on packages, analyze CI/CD pipelines for possible artifact injections, check integrity checks.

Mitigations:

  • Sign artifacts and verify signatures in production
  • Restrictions on authorized repositories, access control in the pipeline
  • Automate integrity scans and build audits


9) Security Logging and Monitoring Failures

What it is: Insufficient logging or missing monitoring that prevents you from detecting and responding to incidents promptly.

Examples: No privileged access logs, unretained or unprotected logs, lack of anomaly alerts.

How Test: Check log coverage, replay events, and verify that they are logged and generate alerts.

Mitigations:

  • Log authentication, authorization, critical error, and administrative events
  • Protect and centralize logs (SIEM), define retention and alerting
  • Incident response procedures and playbooks


10) Server-Side Request Forgery (SSRF)

What it is: An application receives a URL/endpoint from a user, and the server makes requests to internal or external resources using that input, allowing access to internal networks or metadata services.

Examples: URL that allows the attacker to request http://169.254.169.254/latest/meta-data/ on cloud providers, exfiltrating sensitive data.

How to test: Provide internal addresses, IP addresses like 127.0.0.1 or 169.254.169.254, or use tools that detect redirections to internal hosts.

Mitigations:

  • Whitelist allowed domains/addresses; do not use blacklists
  • Validate and normalize URL inputs
  • Use proxies or services that filter outgoing requests; Separate internal network from public services


Useful projects for learning security (OWASP and beyond)

Here is a collection of projects and practical resources, organized by type (testing tools, learning environments, standards, and checklists). These are widely used in the community and are excellent for hands-on learning.


🏛️ Educational environments and apps

  • OWASP Juice Shop — Intentionally vulnerable application, excellent for exercises and CTFs: many modern vulnerabilities present.
  • OWASP WebGoat — Educational lab with step-by-step lessons on various vulnerabilities.
  • Broken Web Applications VM — Collection of vulnerable applications for local/VM testing. These allow you to practice in a controlled environment: attacks, exploitation, and mitigations.


🔧 Testing / scanning tools

  • OWASP ZAP (Zed Attack Proxy) — scanner/proxy for automatic and manual web security tests (traffic interception, fuzzing, active scan).
  • Burp Suite (not OWASP but widely used) — professional proxy for web pentests.
  • OWASP Dependency-Check / Dependency-Track — to identify libraries with known CVEs in dependencies.


📕 Guides, standards, and checklists

  • OWASP Top 10 — to prioritize risks.
  • OWASP ASVS (Application Security Verification Standard) — detailed standard for defining application security requirements (verification levels).
  • OWASP Testing Guide — comprehensive guide to security testing (operational manual).
  • OWASP Cheat Sheet Series — collection of best practices and practical snippets on many topics (XSS, CSRF, password storage, etc.).
  • OWASP Proactive Controls — list of recommended controls for developers.


🤖 Support and Automation Tools

  • ModSecurity — open-source WAF for web-level protection server.
  • Snyk / Dependabot / Renovate — Tools (some commercial) for automatic dependency updates and scanning.
  • Trivy / Clair — Container image vulnerability scanner.


🎓 Recommended learning path (hands-on)

  1. Basic concepts: Read the Cheat Sheets on input validation, authentication, and session management.
  2. Hands-on: Run Juice Shop/WebGoat locally; solve challenges.
  3. Proxy and testing: Learn how to use ZAP or Burp to analyze traffic, test XSS/SQLi/CSRF.
  4. Dependency scanning: Run Dependency-Check on an existing project and fix findings.
  5. Threat modeling & ASVS: Perform threat modeling on a small app and map ASVS requirements.
  6. CI/CD security: Integrate automated scans (SCA, SAST, composition analysis) into the pipeline.
  7. Participate: Contribute to OWASP projects or attend meetups/CTFs to build experience.


Practical examples and useful snippets

1) Prevent SQL Injection (Node.js with parameterized queries)

// using parameterized queries with pg (Postgres)
const text = 'SELECT * FROM users WHERE email = $1';
const values ​​= [userInputEmail];
const res = await client.query(text, values);

2) Prevent XSS (output encoding in HTML)

Principle: Don't insert user input directly into the HTML without escaping it. Use framework escape functions or libraries.

<div>{{ escapeHtml(userComment) }}</div>

3) Protect APIs with JWT and role checking

Validate JWT signatures, check exp, use scopes/roles, and verify server-side that the token matches the requested resource.


Practical tips for beginners

  • Learn with real-world examples: theory and practice combined (e.g., performing an XSS attack on Juice Shop helps you remember mitigations).
  • Follow a checklist: ASVS or Cheat Sheets for what to check for in each release.
  • Automate repetitive checks: Scanners, SCA, and CI policies reduce the burden.
  • Early threat modeling: Fix many issues before they become bugs.
  • Share knowledge: Security-focused code reviews and pair programming help grow the team.
  • Don't strive for perfection: Apply controls proportionate to the risk (risk-based approach).


Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment