What is the most common web vulnerability and how do I prevent it?

Based on the OWASP Top 10, injection vulnerabilities (especially SQL injection) and broken access control are consistently the most common and most impactful. For SQL injection: always use parameterized queries or prepared statements — never concatenate user input into SQL strings. Use an ORM that uses parameterized queries by default (Prisma, Drizzle, SQLAlchemy). For broken access control (IDOR): always scope database queries to the authenticated user's ID, never trust IDs from the request body or URL params alone. Enable Row Level Security at the database level (Supabase RLS) as a defense-in-depth layer. These two controls prevent the majority of real-world exploits.

Why is storing JWTs in localStorage dangerous, and what is the alternative?

localStorage is accessible to any JavaScript running on the page, including injected scripts from XSS vulnerabilities. An attacker who exploits XSS can run document.cookie or localStorage.getItem("token") and exfiltrate the JWT, gaining full session access. HttpOnly cookies solve this: the HttpOnly flag makes cookies inaccessible to JavaScript entirely — not even to your own code, and not to injected code. The browser still sends them automatically with requests. Combine HttpOnly with Secure (HTTPS only) and SameSite=Strict (prevents CSRF). The trade-off: cookie-based auth is slightly more complex to implement for cross-domain SPAs, but the security benefit is substantial.

What is the difference between XSS and CSRF attacks?

XSS (Cross-Site Scripting) injects malicious scripts into a page that execute in the victim's browser in the context of your origin — giving the attacker the ability to read DOM content, steal cookies (if not HttpOnly), make authenticated requests, and keylog form inputs. The payload is served from your own domain. CSRF (Cross-Site Request Forgery) tricks the victim's browser into making authenticated requests to your server from a different origin — the attacker does not need to see the response, they just need the request to happen (e.g., transfer funds, change email). The browser automatically includes cookies in cross-origin requests unless SameSite is set. Defense for XSS: output encoding, CSP headers. Defense for CSRF: SameSite cookies, CSRF tokens.

How do I safely handle file uploads to prevent security vulnerabilities?

File uploads are a common attack vector. Key controls: (1) Validate file type on the server by reading the file's magic bytes (first bytes of the file), not just the extension or MIME type the client claims — client-supplied MIME types can be spoofed. (2) Rename the file on the server to a random UUID — never use the original filename which may contain path traversal sequences (../../etc/passwd). (3) Store uploaded files outside the web root or in blob storage (S3, Supabase Storage) — never in a directory that is directly served by your web server. (4) Virus scan files if your application processes document types. (5) Set a maximum file size and validate it on both client and server. (6) Serve uploaded files with Content-Disposition: attachment to prevent browsers from executing them as HTML.

What is the purpose of security headers like CSP, HSTS, and X-Frame-Options?

Security headers instruct browsers to enforce additional security policies. Content-Security-Policy (CSP) restricts which scripts, styles, and resources the page can load — even if XSS injects a script tag, CSP can prevent it from executing if the source is not on the allowlist. HTTP Strict-Transport-Security (HSTS) tells browsers to only ever connect to this domain over HTTPS, even if the user types http:// — preventing SSL stripping attacks. X-Frame-Options: DENY prevents your pages from being embedded in iframes on other sites, stopping clickjacking attacks where an attacker renders your page invisibly and tricks users into clicking hidden buttons. X-Content-Type-Options: nosniff prevents browsers from interpreting files as a different MIME type than declared, preventing MIME confusion attacks.

Engineering·11 min read·June 21, 2026

🔒 Web Security in Practice: OWASP Top 10 for Engineers

A practical guide to the OWASP Top 10 web security vulnerabilities for software engineers: SQL injection, XSS, SSRF, broken authentication, insecure direct object references, security misconfiguration, vulnerable dependencies, and cryptographic failures — with vulnerable vs secure code examples.

📖Full-Stack SaaS with Next.js, Supabase & Groq AI (Full Access)

View →

Why Every Engineer Must Understand Security

Security is not the security team's job — it is every engineer's job. The OWASP Top 10 is the most widely used reference for web application security risks, maintained by the Open Web Application Security Project. This guide covers the most critical vulnerabilities with real code examples showing the vulnerable version and the correct fix, so you can recognize and prevent them in your own code.

Topics covered

OWASP Top 10 guideSQL injection preventionXSS cross-site scriptingSSRF server-side request forgeryJWT security pitfallsbroken authentication OWASPIDOR insecure direct object referencesecurity misconfiguration webnpm audit vulnerable dependenciescryptographic failures OWASPweb application securityinput validation securitycontent security policyparameterized queries SQLbcrypt password hashingHTTPS HSTS securitysecure cookie settingsrate limiting brute forceweb security engineer guide