Skip to main content

Web Security

Web Security

Table of Contents

Quick Answer

Web security is the practice of protecting web applications and their users from attack. Most web attacks come down to one of two mistakes: trusting input that should have been treated as hostile, or trusting that a request really came from the user. This page maps the 21 web security guides on Insecure Lab by class of attack, shows where each sits in the OWASP Top 10:2025, and sets out the defence layers that stop them.

What is Web Security?

A web application takes requests from anyone on the internet, runs code on a server, and sends back pages and scripts that run in someone else's browser. Web security is everything that keeps that arrangement safe: how the application handles untrusted input, how it knows who a user is and keeps their session theirs, what it permits the browser to do, and how it is configured, deployed and tested.

Two things make the web distinctive. The attacker and the victim are often different people, with the application in the middle: a script planted through the site runs in another visitor's browser. And the browser is helpful by design, attaching cookies and following instructions from whichever page it has open. Most of the attacks below abuse one of those two facts.

If your application is mostly endpoints called by apps and other services, read this alongside our API security guide; the ideas are the same and the emphasis differs.

Web Attacks by Class

Every web security guide on this site, grouped by the kind of mistake the attack exploits.

ClassWhat goes wrongGuides
Injection and input handling Untrusted input is interpreted as code, a query, a path or a header. Input Validation Attacks · Cross-Site Scripting (XSS) · SQL Injection · Second-Order SQL Injection · Bobby Tables · XXE Attack · CRLF Injection · Directory Traversal · XSS vs SQL Injection
Cross-site and request forgery Another site makes the browser, or the server, act in the victim's name. CSRF Attack · Clickjacking · Clickjack Protection · XSS vs CSRF · SSRF vs CSRF
Sessions and state The attacker takes over, plants or rewrites the state that identifies a user. Session Hijacking · Cookie Tossing · Parameter Tampering
Third-party scripts and delivery Code the site did not write runs in its pages, or a payload is assembled in the browser. Formjacking · Magecart Attack · HTML Smuggling
Testing and assurance How weaknesses are found before an attacker finds them. SAST and DAST

OWASP Top 10:2025 Map

The OWASP Top 10 groups web application risks into ten categories. The table shows where the guides on this site sit in the 2025 edition. Placements follow the weakness identifiers OWASP itself lists under each category, so some may surprise you: clickjacking and parameter tampering fall under Insecure Design, and XXE under Security Misconfiguration.

CategoryGuides on Insecure Lab
A01 Broken Access Control CSRF Attack · Directory Traversal · SSRF vs CSRF · Broken Object Level Authorization
A02 Security Misconfiguration XXE Attack · Security Headers Checklist
A03 Software Supply Chain Failures No dedicated guide
A04 Cryptographic Failures Cryptography
A05 Injection Cross-Site Scripting (XSS) · SQL Injection · CRLF Injection · Input Validation Attacks
A06 Insecure Design Clickjacking · Parameter Tampering · Privilege Escalation
A07 Authentication Failures Session Hijacking · Brute Force Attack · Password Hacking
A08 Software or Data Integrity Failures Formjacking · Magecart Attack
A09 Security Logging and Alerting Failures Intrusion Detection System
A10 Mishandling of Exceptional Conditions No dedicated guide

This is an independent educational mapping by Insecure Lab. It is not affiliated with or endorsed by OWASP. The official list is linked under Sources. For a working review list, use our OWASP Top 10 Checklist.

Defence Layers

No single control stops everything. Web security works in layers, so that when one is missing or bypassed, another still holds.

LayerWhat it doesRead more
Validate input, encode output Treat every value from the browser as untrusted; encode it for the context it lands in. Input Validation Attacks · XSS
Parameterised queries Keep data and commands separate, so input can never change the shape of a query. SQL Injection
Protect sessions and cookies Secure, HttpOnly, SameSite cookies; rotate session identifiers at login; require proof of intent on state changes. Session Hijacking · CSRF
Authorize on the server Never trust a value because the interface would not have sent it. Check the record, the action and the fields. Parameter Tampering · API Security
Security headers Content Security Policy, HSTS and frame restrictions tell the browser what the page is allowed to do. Security Headers Checklist · Clickjacking
Control third-party scripts Load only what you need, pin it with integrity hashes, and restrict where scripts may come from. Formjacking
Test in the pipeline Static and dynamic analysis on every change, plus a checklist review before release. SAST and DAST · OWASP Top 10 Checklist

Learning and Testing Safely

  • Practise on intentionally vulnerable training applications, in a local lab, or on systems you own.
  • Test anything else only with written permission and an agreed scope.
  • Learn each attack together with its defence. Knowing why encoding stops XSS is more useful than knowing ten payloads.
  • Check what you learn against primary sources: OWASP, MDN and the standards themselves change, and tutorials go stale.

Web Security Learning Path

Input Validation Attacks Start here: why untrusted input is the root of most web attacks. Cross-Site Scripting (XSS) Script injected into a trusted page, and how encoding stops it. SQL Injection Input that rewrites a database query. CSRF Attack Requests a logged-in browser never meant to send. Session Hijacking Taking over a session after login. Clickjacking Clicks redirected through an invisible frame. Security Headers Checklist The browser-side controls every site should set. API Security The same ideas applied to the APIs behind the pages.

FAQs

Web security is the practice of protecting websites and web applications, and the people who use them, from attack. It covers how an application handles untrusted input, how it identifies users and keeps their sessions safe, what it allows the browser to do, and how it is configured and tested.

Cross-site scripting, SQL injection and cross-site request forgery are ranked first, second and third in the 2025 CWE Top 25. Broken access control heads the OWASP Top 10:2025. Most web attacks come down to one of two mistakes: trusting input, or trusting that a request really came from the user.

The OWASP Top 10 is a list of the ten most critical categories of web application security risk, published by the OWASP Foundation. The current edition is 2025. It is an awareness document that tells you where to look first, not a complete standard.

They overlap heavily. Web security includes everything the browser is involved in: scripts, cookies, frames and headers. API security concentrates on what happens when clients call endpoints directly, where authorization on every record and field matters most. See our API security guide.

Start with input handling, because it underlies most attacks: read Input Validation Attacks, then XSS and SQL injection. Then move to sessions and request forgery. Practise only in lab environments or on systems you have permission to test.

No. A firewall filters known bad patterns and buys time, and it cannot know whether a request is authorized for a particular record or whether a value is safe in the place your code uses it. Fix the weakness in the application and treat the firewall as an extra layer.

Sources and further reading