Web security and the OWASP Top 10

01The OWASP Top 10 in plain words

OWASP (the Open Worldwide Application Security Project) publishes the Top 10 from real vulnerability data and community surveys. The 2025 edition reads: A01 Broken Access Control (users reach data or actions they should not; SSRF is now part of this category); A02 Security Misconfiguration; A03 Software Supply Chain Failures (vulnerable or compromised dependencies, build tools and pipelines); A04 Cryptographic Failures; A05 Injection (SQL, command and also XSS); A06 Insecure Design; A07 Authentication Failures; A08 Software or Data Integrity Failures; A09 Security Logging and Alerting Failures; A10 Mishandling of Exceptional Conditions (errors that fail open or leak details). Use it as awareness and a review checklist, not as a complete standard; for detailed requirements, OWASP's Application Security Verification Standard (ASVS) and the API Security Top 10 go deeper.

02Broken access control, SSRF and CSRF

Broken access control is the most common serious flaw. Classic example: GET /api/orders/1043 returns any order, because the code checks that the user is logged in but not that the order is theirs. This is called IDOR (insecure direct object reference). The fix is to check ownership or permission on every request on the server, ideally through central policies, deny by default and return 404 for objects the user may not see. Server-side request forgery (SSRF) happens when your server fetches a URL supplied by the user, such as an image import, and an attacker points it at internal addresses or cloud metadata endpoints. Allow-list hosts and schemes, resolve and block private IP ranges, and disable redirects. Cross-site request forgery (CSRF) tricks a logged-in browser into sending a state-changing request; defend with SameSite cookies, CSRF tokens and checking the Origin header.

• Authorise every object access on the server, not in the UI.
• Deny by default; test with a second user account.
• For URL fetching: allow-list, block private ranges, no redirects.

03Injection and XSS

Injection happens when user input is treated as code. In SQL injection, a search box containing ' OR 1=1 -- changes the meaning of a query built by string concatenation, leaking or deleting data. The fix is parameterised queries, where data is sent separately from the SQL, which every modern driver and ORM supports; be careful with raw query helpers and dynamic column names, which need allow-lists. The same principle applies to shell commands, LDAP and template engines. Cross-site scripting (XSS) is injection into HTML: an attacker stores a script in a review or profile name and it runs in other users' browsers, stealing sessions or performing actions. Frameworks such as React escape output by default; the danger zones are dangerouslySetInnerHTML, v-html, unescaped Blade output, and URLs in href attributes. Sanitise rich HTML with a proven library and add a Content Security Policy as a second layer.

1import { Pool } from "pg";
2const db = new Pool();
3 
4// Vulnerable: input becomes part of the SQL text
5// db.query("SELECT * FROM users WHERE email = '" + email + "'");
6 
7// Safe: input is sent as a parameter, never parsed as SQL
8export async function findUser(email: string) {
9  const { rows } = await db.query(
10    "SELECT id, email FROM users WHERE email = $1",
11    [email],
12  );
13  return rows[0] ?? null;
14}

04Misconfiguration and secure headers

Many breaches need no clever exploit: debug mode left on in production, a public storage bucket, default admin passwords, verbose error pages with stack traces, directory listing, an exposed .env or .git folder, a database port open to the internet. Prevent these with configuration as code, environment-specific settings, and checks in the deploy pipeline. Security headers add browser-side protection. HTTP Strict Transport Security forces HTTPS. A Content Security Policy (CSP) tells the browser which sources of scripts, styles and images are allowed, which blocks most injected scripts; start in report-only mode, then enforce, and prefer nonces or hashes over 'unsafe-inline'. X-Content-Type-Options stops MIME sniffing, frame-ancestors in CSP prevents clickjacking, and Referrer-Policy and Permissions-Policy limit what leaks or is allowed. Mark cookies Secure, HttpOnly and SameSite.

1# nginx: baseline security headers (adapt CSP sources to your app)
2add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
3add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https://cdn.example.com; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" always;
4add_header X-Content-Type-Options "nosniff" always;
5add_header Referrer-Policy "strict-origin-when-cross-origin" always;
6add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
7server_tokens off;

05Secrets, dependencies and the supply chain

Secrets (API keys, database passwords, signing keys) belong in environment variables or a secrets manager, never in the repository, client bundles, logs or error messages. Give each secret the least privilege it needs, separate them per environment, and rotate them on a schedule and immediately after any suspected leak; a leaked key that cannot be rotated quickly is a design flaw. Add secret scanning to the repository and CI so mistakes are caught before they are pushed. Modern apps are mostly third-party code, which is why supply-chain failures are now in the top three. Commit lockfiles, run dependency audits (npm audit, composer audit, Dependabot or Renovate), pin and review CI actions, remove unused packages, and be suspicious of new packages with tiny download counts or install scripts. Keep frameworks and runtimes on supported versions.

06Rate limiting, bots, reviews and pentests

Every endpoint that can be abused needs limits: login, OTP and password-reset requests, search, contact forms, file uploads and public APIs. Rate limit by user, IP and API key, with stricter limits on authentication; lock or slow accounts after repeated failures, and add a CAPTCHA or proof-of-work challenge only where abuse is real. A CDN or WAF in front absorbs volumetric attacks and blocks known bad patterns. Uploads need their own care: check type by content rather than extension, cap sizes, guard against decompression bombs and serve files from a separate domain or through signed links. Then make security a process. Threat-model new features ('what could a malicious tenant do here?'), include security items in code review, run SAST and dependency scans in CI, and commission an external penetration test before major launches and periodically, fixing findings by severity.

• Strict limits on login, OTP and reset flows.
• Log security events (failed logins, permission denials) and alert on spikes.
• Pentests find what you missed; they do not replace secure habits.

07Passwords, sessions and tokens done properly

Store passwords with a slow, memory-hard hash. OWASP's Password Storage Cheat Sheet recommends Argon2id with at least 19 MiB of memory, 2 iterations and parallelism 1; scrypt when Argon2id is unavailable; bcrypt only for legacy systems, with a work factor of 10 or more and its 72-byte input limit in mind. Check new passwords against known breached lists rather than forcing odd composition rules. For sessions, opaque random IDs stored server-side are simple and instantly revocable. If you use JWTs, pin the accepted algorithm on the server (never trust the token's alg header), validate issuer, audience and expiry, keep access tokens short-lived, and rotate refresh tokens on every use, treating reuse of an old refresh token as theft and revoking the whole family. Regenerate session IDs after login and privilege changes to prevent session fixation.

1import argon2 from "argon2";
2 
3// OWASP minimum: Argon2id, 19 MiB memory, 2 iterations, parallelism 1
4export function hashPassword(password: string) {
5  return argon2.hash(password, {
6    type: argon2.argon2id,
7    memoryCost: 19456, // KiB
8    timeCost: 2,
9    parallelism: 1,
10  });
11}
12 
13export function verifyPassword(hash: string, password: string) {
14  return argon2.verify(hash, password); // parameters are read from the hash
15}

08A strict Content Security Policy and Trusted Types

Allow-list policies (script-src with many CDN hosts) are often bypassable, because one allowed host may serve a JSONP endpoint or an old library an attacker can abuse. A strict policy relies on nonces or hashes instead: the server generates a fresh random nonce per response, puts it on every legitimate script tag and in the header. Adding 'strict-dynamic' lets scripts loaded by a trusted script run too, so tag managers and bundlers keep working, while injected markup without the nonce is blocked. Combine it with object-src 'none' and base-uri 'none' or 'self'. For DOM-based XSS, Trusted Types (require-trusted-types-for 'script') makes the browser refuse raw strings in dangerous sinks such as innerHTML, forcing code through a reviewed sanitising policy. Roll out in report-only mode first and fix violations.

1Content-Security-Policy:
2  script-src 'nonce-r4nd0mBase64Value' 'strict-dynamic';
3  object-src 'none';
4  base-uri 'none';
5  frame-ancestors 'none';
6  require-trusted-types-for 'script';
7  report-to csp-endpoint

09SSRF in depth: DNS rebinding and cloud metadata

Blocking private IPs in the URL string is not enough. Attackers use alternative notations (decimal or IPv6-mapped addresses), redirects to internal hosts, and DNS rebinding, where a hostname resolves to a public IP during your check and to 127.0.0.1 or 169.254.169.254 a moment later when you connect. Robust defences resolve the hostname once, validate every resolved address against blocked ranges (loopback, private, link-local, unique local IPv6), then connect to that exact IP while sending the original Host header, and re-validate on each redirect or disable redirects. Better still, route all user-driven fetches through an egress proxy that enforces the policy centrally and has no access to internal networks. On AWS, require IMDSv2, whose session token must be obtained with a PUT request, which blocks most simple SSRF attempts against instance credentials.

• Validate resolved IPs, not the URL text; pin the connection to them.
• Block loopback, RFC 1918, link-local and IPv6 unique-local ranges.
• Send user-driven fetches through an isolated egress proxy.

10Cookies, CORS and browser isolation

Cookie attributes are a cheap, strong layer. Secure and HttpOnly keep session cookies off plain HTTP and away from JavaScript. SameSite=Lax, the default in modern browsers when unspecified, blocks most cross-site POSTs; use Strict for highly sensitive cookies and None; Secure only when you genuinely need cross-site use. The __Host- prefix forces Secure, Path=/ and no Domain attribute, so a compromised subdomain cannot overwrite the cookie. CORS is often misread: it relaxes the same-origin policy, it does not protect your API. Never reflect arbitrary Origin values together with Access-Control-Allow-Credentials: true; keep an explicit allow-list. For stronger isolation, Cross-Origin-Opener-Policy: same-origin separates your window from cross-origin popups, and Cross-Origin-Resource-Policy limits which sites may embed your resources.

1Set-Cookie: __Host-session=9f1c...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600
2 
3Access-Control-Allow-Origin: https://app.example.com
4Access-Control-Allow-Credentials: true
5Vary: Origin
6 
7Cross-Origin-Opener-Policy: same-origin
8Cross-Origin-Resource-Policy: same-site