Cybersecurity Fundamentals for Web Applications

Security — Aug 30, 2024

A technical overview of protecting user data, sanitizing inputs, and defending against common attacks.

Web application security is not a feature you add at the end of a project. It is a discipline that must be embedded in every decision from architecture through deployment. The consequences of getting it wrong range from regulatory fines and reputational damage to direct financial loss and harm to real users. This article covers the foundational concepts every web developer and technical product leader needs to understand.

The OWASP Top Ten

The Open Web Application Security Project (OWASP) maintains a regularly updated list of the ten most critical security risks for web applications. Understanding these is the starting point for any security discussion:

Broken Access Control is the most prevalent issue — users accessing resources or performing actions they are not authorized for. Every API endpoint must independently verify that the authenticated user has permission to perform the requested operation. Never rely on the UI to hide actions the backend permits.

Cryptographic Failures cover the misuse, weakness, or absence of encryption for sensitive data. Passwords must be hashed using a modern, slow algorithm (Argon2, bcrypt, or scrypt). Data in transit must use TLS 1.2 or higher. Sensitive data at rest must be encrypted. Hardcoded secrets in source code are a cryptographic failure.

Injection — SQL injection, command injection, and their relatives — occurs when user-supplied input is incorporated into a query or command without proper sanitization. The defense is parameterized queries and prepared statements for database access, and strict input validation for everything else. ORM libraries help but are not sufficient on their own.

Security Misconfiguration is the most broadly applicable category: default credentials left unchanged, unnecessary services exposed, debug mode enabled in production, overly permissive CORS headers, missing security headers. Security configuration must be audited explicitly before every deployment.

Input Validation and Output Encoding

Every piece of data that enters your application — from query strings, form fields, HTTP headers, file uploads, and API payloads — must be treated as potentially malicious until proven otherwise. Validate on the server side (client-side validation is a UX feature, not a security control). Define what valid input looks like (allowlisting) rather than trying to block known bad input (denylisting).

Cross-Site Scripting (XSS) occurs when user-supplied data is rendered in a browser without encoding. A user who can inject <script>alert(document.cookie)</script> into your application can steal session tokens from other users. The defense is consistent HTML encoding of user content on output and a strong Content Security Policy header.

Authentication and Session Management

Authentication failures are devastating because they provide attackers with legitimate access to real user accounts. Key controls include:

Enforce strong password requirements and check against known-breached password lists (the HaveIBeenPwned API provides a privacy-preserving lookup).
Implement multi-factor authentication, especially for administrative accounts.
Use secure, HTTP-only, SameSite cookies for session tokens. Never store session tokens in localStorage.
Invalidate sessions on logout, password change, and after a configurable inactivity period.
Rate-limit and lock out after repeated authentication failures to prevent brute-force attacks.

Dependency Management

The average web application includes hundreds of third-party packages. Each package is an attack surface. Supply chain attacks — compromising a widely-used package to distribute malicious code — are an increasing threat. Controls include: pinning dependency versions and verifying checksums, running automated vulnerability scans (npm audit, Dependabot, Snyk) in your CI pipeline, and auditing the permissions requested by packages before adding them.

Security Headers

A correctly configured set of HTTP response headers significantly reduces the exploitability of several vulnerability classes:

Content-Security-Policy: restricts which scripts, styles, and resources can be loaded.
Strict-Transport-Security: forces all future requests to use HTTPS.
X-Frame-Options / frame-ancestors: prevents clickjacking by disallowing your pages from being embedded in iframes on other domains.
X-Content-Type-Options: prevents MIME type sniffing.
Referrer-Policy: controls what referrer information is sent with requests.

Use securityheaders.com to evaluate your current header configuration.

The Security Mindset

The most important security investment is not a specific tool or control — it is a team culture that considers adversarial conditions by default. Threat model new features before building them. Include security review in your code review process. Run penetration tests against production before major launches. Build a clear, published process for external researchers to report vulnerabilities.

Security is not a destination. It is a continuous practice.

Get in touch