Security is not a feature you add at the end. It's a discipline integrated at every stage of development, from conception to deployment.
The OWASP Top 10 remains the reference for understanding the most critical web application vulnerabilities. In 2023, the top three remain unchanged: Broken Access Control, Cryptographic Failures, and Injection. These aren't exotic bugs — they're fundamental design errors found in hundreds of production applications today.
Most exploited OWASP vulnerabilities
Broken Access Control — a user accesses resources or actions they don't own. It's the number one vulnerability: endpoints with no role verification, predictable IDs not checked server-side (IDOR), silent privilege escalation. The rule: deny by default, systematic server-side checks, never rely on client-side alone.
Cryptographic Failures — sensitive data exposed due to inadequate encryption. Passwords stored in plain text or hashed with MD5/SHA1, personal data unencrypted at rest, HTTP instead of HTTPS, secret keys hardcoded in source or unprotected environment variables.
Injection — SQL, LDAP, NoSQL, OS command injection. Whenever untrusted data is interpreted as a command rather than data. Prepared statements eliminate SQL injection. Strict input validation eliminates the rest. Generative AI worsens this risk: it regularly produces string concatenations where parameterised queries are required.
Security Misconfiguration — missing HTTP headers, active default accounts, stack traces exposed in production, public S3 buckets, unnecessarily open ports. The most mundane vulnerability and often the fastest to exploit.
Vulnerable and Outdated Components — a dependency with an unpatched critical CVE is an open door. Automating dependency monitoring (Dependabot, Renovate, Snyk) is essential in any serious CI/CD pipeline.
Non-negotiable practices
- Authentication: short-lived JWT tokens (15 minutes), secure refresh token in HttpOnly cookie, refresh token rotation on every use. Implement two-factor authentication for all sensitive access.
- Passwords: hash with bcrypt (cost ≥ 12) or argon2id — never MD5, SHA1 or bare SHA256. Always verify using a dedicated library, never a home-grown implementation.
- SQL: prepared statements without exception. ORMs like Hibernate protect natively, provided you don't bypass them with unparameterised native SQL.
- Inputs: validate and sanitise server-side, not just client-side. Whitelist over blacklist. Constrain the size, type and format of every field.
- Transport: HTTPS everywhere, HSTS with a long
max-ageandincludeSubDomains, automatic HTTP → HTTPS redirect. Auto-renewed certificates (Let's Encrypt, ACM). - Headers: Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. A few lines of configuration that neutralise entire classes of XSS and clickjacking attacks.
Shift Left Security: embedding security in the development cycle
The most effective approach is not an annual audit — it's integrating security at every stage of development.
In CI/CD: static analysis tools (SAST) like SonarQube, Semgrep or Checkmarx detect dangerous patterns before merge. Dependency scanners (OWASP Dependency-Check, Snyk) flag critical CVEs automatically. Dynamic security tests (DAST) like OWASP ZAP can be integrated into staging pipelines.
In code reviews: a short but systematic security checklist — input validation, authorisation handling, secrets in code, logs exposing sensitive data — significantly raises a team's average security level without slowing delivery.
In training: developers who understand why SQL injection works make different mistakes than those who have only learned to use an ORM. Interactive labs (HackTheBox, OWASP WebGoat, TryHackMe) are more effective than theoretical courses.
Annual penetration testing by an external team completes the picture — not as the primary safety net, but as independent validation. Perfect security doesn't exist: the goal is to make an attack costly enough that the attacker moves on to an easier target.