DEV Community

SIKOUTRIS
SIKOUTRIS

Posted on

Website Security Checks Every Developer Should Run Before Going Live in 2026

#security #webdev #devops #javascript

Launching a website without a security audit is like opening a shop and leaving the back door unlocked. In 2026, with automated bots scanning the web within minutes of a new domain going live, security hygiene is table stakes — not an optional extra.

Here are the critical checks every developer should run before pushing to production.

1. HTTP Security Headers

Missing security headers are the most common — and most avoidable — vulnerability class. At minimum, your site should serve:

  • Content-Security-Policy — restricts which scripts, styles, and resources can load
  • X-Frame-Options — prevents clickjacking attacks
  • Strict-Transport-Security — forces HTTPS connections
  • X-Content-Type-Options: nosniff — blocks MIME-type sniffing
  • Referrer-Policy — controls how much referrer information is sent
  • Permissions-Policy — limits browser feature access (camera, geolocation, etc.)

A missing CSP is one of the top reasons sites get flagged in security audits. You can verify all headers in one pass using an automated tool like check.softwarespiegel.de which scans headers, SSL, and mixed-content issues simultaneously.

2. SSL/TLS Configuration

SSL is not binary. Beyond having a certificate, check:

  • Protocol version (TLS 1.2 minimum, TLS 1.3 preferred)
  • Cipher suite strength
  • Certificate expiry date (automate renewal with Let's Encrypt + certbot)
  • HSTS preload status

3. Mixed Content

Serving HTTPS but loading HTTP sub-resources (images, scripts, fonts) degrades security and will cause browsers to block resources silently. Audit using browser DevTools (Console tab) or automated scanners.

4. Open Redirects

If your application handles redirect URLs passed as query parameters, test for open redirect vulnerabilities:

https://yoursite.com/redirect?url=https://attacker.com
Enter fullscreen mode Exit fullscreen mode

This is frequently exploited in phishing campaigns.

5. Dependency Audit

For JavaScript projects:

npm audit
# or
yarn audit
Enter fullscreen mode Exit fullscreen mode

For PHP/WordPress: use WP CLI wp plugin list and cross-reference CVE databases. Outdated plugins are the #1 WordPress attack vector.

6. Exposed Environment Files

A surprising number of sites accidentally expose .env, config.php, or wp-config.php.bak files. Test:

curl -I https://yoursite.com/.env
curl -I https://yoursite.com/wp-config.php.bak
Enter fullscreen mode Exit fullscreen mode

Anything other than a 403 or 404 is a critical finding.

7. Clickjacking Test

Check whether your site can be embedded in an iframe:

// Paste in browser console while on your site
console.log(window.top === window.self ? "Not framed" : "Can be framed");
Enter fullscreen mode Exit fullscreen mode

If framed, add X-Frame-Options: DENY or a frame-ancestors CSP directive.

Build Security Into Your Deployment Pipeline

The most efficient approach is to automate these checks so they run on every deploy, not just at launch. A CI/CD pipeline with automated security header validation, dependency scanning, and SSL checks removes human error from the equation.

Manual spot checks before launch are fine, but continuous automated monitoring catches regressions that slip in with every update.

Have you integrated security checks into your CI/CD pipeline? Share your stack in the comments.

Top comments (0)