The Security That Should Be Standard and Often Isn’t
Website security failures — SQL injection attacks, cross-site scripting, broken authentication, exposed sensitive data — appear in the OWASP Top 10 list year after year because they appear in real production websites year after year. These aren’t obscure, sophisticated attack vectors: they’re well-documented vulnerability classes with well-understood mitigations that nonetheless appear in newly launched websites with troubling regularity because security isn’t adequately integrated into the development and pre-launch checklist.
The security checklist that follows isn’t comprehensive — full web application security is a deep and specialized field. It covers the vulnerabilities that are most commonly exploited in the real world against the widest range of website types, and the mitigations that address them without requiring security specialization to implement.
HTTPS Everywhere: Non-Negotiable in 2026
HTTPS is not an optional security upgrade — it’s the baseline expectation of modern browsers, search engines, and users. Google Chrome marks non-HTTPS sites as ‘Not Secure’ in the address bar. Most browsers block certain capabilities (geolocation, camera/microphone access, service workers) on non-HTTPS pages. Search engines have confirmed HTTPS as a (minor) ranking signal. Let’s Encrypt provides free SSL certificates that eliminate the historical cost barrier, and most hosting providers offer one-click HTTPS setup.
Beyond basic HTTPS: configure HTTP Strict Transport Security (HSTS) headers, which tell browsers to always use HTTPS for your domain even if someone manually types ‘http://’ — this prevents SSL stripping attacks. Submit your domain to the HSTS preload list for even stronger protection. Ensure all resources (images, scripts, stylesheets) are loaded over HTTPS — mixed content (HTTPS page loading HTTP resources) triggers browser warnings and fails increasingly strict browser security policies.
SQL Injection and Parameterized Queries
SQL injection remains in the OWASP Top 10 not because it’s newly discovered but because developers still build SQL queries by concatenating user input into query strings: ‘SELECT * FROM users WHERE name = “‘ + userInput + ‘”‘. User input that contains SQL syntax (‘; DROP TABLE users;–) executes as SQL rather than being treated as a data value, allowing attackers to read, modify, or delete database content.
The complete mitigation is parameterized queries (also called prepared statements): the query structure is defined first, then user data is passed as a separate parameter that the database treats as data rather than syntax. Every major programming language and database library supports parameterized queries; there’s no technical barrier to using them. If an existing codebase has string-concatenated SQL queries (search for string concatenation in query construction), this is a critical finding that warrants immediate remediation before any other security work.
Cross-Site Scripting (XSS) and Content Security Policy
Cross-site scripting (XSS) occurs when user-supplied input is displayed on a web page without being properly escaped, allowing injected JavaScript to run in other users’ browsers. A comment field that accepts ‘<script>alert(document.cookie)</script>’ and displays it unescaped to other users who view the page executes arbitrary JavaScript in their browser context — allowing cookie theft, session hijacking, and malicious redirects.
The primary mitigations: escape all user-supplied content before displaying it in HTML (using your framework’s built-in output escaping, not manual string replacement that misses cases), and implement a Content Security Policy (CSP) header that restricts what JavaScript sources can execute in the page context. CSP is a defense-in-depth measure that limits the impact of XSS even when an injection occurs — a strict CSP that blocks inline scripts and external script sources significantly limits what an XSS payload can accomplish.
Authentication, Session Management, and Sensitive Data
Use established authentication libraries rather than building authentication from scratch. Authentication has many subtle failure modes that purpose-built libraries have been designed and tested against: session fixation, predictable session tokens, insecure password storage, and timing attacks on credential comparison are all categories where rolling your own implementation is likely to produce vulnerabilities that established libraries have addressed.
Password storage specifically: passwords must be hashed with a modern, slow hashing algorithm (bcrypt, scrypt, Argon2 — not MD5, not SHA-1, not even SHA-256 alone) that makes brute-force attacks against leaked password hashes computationally expensive. If existing systems are storing passwords in any other format, this is an immediate security incident waiting to happen. Environment variables for secrets (API keys, database credentials) rather than hard-coded in source files that may be version-controlled or accidentally exposed is the bare minimum for secret management — use a proper secret management solution for production systems.