The Website Security Checklist Every New Site Needs Before Launch

Everything below can be checked from outside your infrastructure — by requesting your site the way a browser does and reading what comes back: whether HTTP gets redirected to HTTPS, whether the TLS certificate is trusted, and which security headers the server sends.

This is not a complete security audit. It doesn't touch your application code, your authentication logic, your database, your dependencies, or your infrastructure. Think of it as the externally observable transport-and-headers layer — an important baseline, and a genuinely useful thing to get right before launch, but one piece of a much larger picture.

What HTTPS enforcement means

A domain can usually be reached over both plain HTTP and HTTPS. If a visitor types your domain without "https://", clicks an old link, or follows a bookmark saved years ago, their first request often goes out over plain HTTP by default. HTTPS enforcement means your server immediately redirects that request to the HTTPS version instead of serving content — or worse, a login form — over an unencrypted connection where it could be read or altered in transit.

How to check it yourself

Request the plain HTTP version of your site and look at the response:

curl -I http://yourdomain.com

You want a 301 or 308 status with a Location: https://yourdomain.com header. If you instead get a 200 with real page content, the site is serving HTTP directly and isn't enforcing HTTPS.

This is the first check Nyrolo runs on every scan: it requests the plain HTTP version of a site first, then confirms it gets redirected to HTTPS — the same request path a browser takes when someone types a bare domain.

Trusted certificates

A TLS certificate needs three things to be trusted by a browser: it has to be issued by a certificate authority (CA) that the browser's trust store recognizes, it has to match the hostname being requested, and it has to be within its validity window. Get any one of those wrong — a self-signed cert, a certificate issued for a different domain, an expired one — and visitors see a full-page warning instead of your site.

Certificate expiration

Certificates expire, typically every 90 days for free issuers like Let's Encrypt or up to a year for paid ones. If renewal isn't automated, a certificate can lapse silently and take the whole site down with a browser warning. Most hosting platforms and tools like Certbot automate renewal — worth confirming that's actually configured rather than assumed.

A quick way to check both trust and expiration from the command line:

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates -issuer

Or just open your site in a browser and click the padlock icon — it shows the same issuer and expiration information.

An HTTPS redirect helps, but it doesn't fully close the gap: that very first request, before the redirect happens, still goes out over plain HTTP for a moment — and on a hostile network, that moment is enough for the connection to be intercepted or downgraded. The Strict-Transport-Security header fixes this by telling the browser to remember, for a set period, to only ever connect to your domain over HTTPS — skipping the plain-HTTP request entirely on future visits, redirect or not.

The header's main setting is max-age, a number of seconds for how long the browser should remember this. A short max-age (a day or two) barely helps; a common baseline is six months (max-age=15552000) or a year.

Why CSP matters

A Content-Security-Policy header tells the browser which sources of scripts, styles, images, and other resources are allowed to load on your page. It exists mainly to contain cross-site scripting (XSS): even if an attacker manages to inject a script tag somewhere on your page, a good CSP stops the browser from executing anything that didn't come from an approved source.

Starting carefully with CSP

CSP is easy to get wrong in a way that either breaks your site or does nothing. A policy built around 'unsafe-inline' or a wildcard * source technically satisfies "has a CSP" while providing little real protection. Most teams start with Content-Security-Policy-Report-Only, which logs violations without blocking anything, tighten the policy based on what actually shows up, and only then switch to enforcing it.

Clickjacking works by loading your page inside an invisible or disguised <iframe> on an attacker's site, then tricking a visitor into clicking on what looks like a harmless button — but the click actually lands on your page underneath, on a real button like "confirm purchase" or "delete account." The X-Frame-Options header (or the newer frame-ancestors directive in CSP) tells browsers whether your page is allowed to be framed at all, and by whom — set to DENY or SAMEORIGIN, it shuts this attack down entirely.

Browsers don't always trust the Content-Type header a server sends — some will inspect the actual bytes of a response and guess the content type themselves, a behavior called MIME-sniffing. That guessing can turn a file your server intended as an inert download or image into something the browser decides to render as HTML or execute as a script, which becomes a real problem anywhere user-controlled content gets served. The X-Content-Type-Options: nosniff header simply tells the browser to trust the declared content type and stop guessing.

When your page links to another site, or loads a resource from one, the browser can send a Referer header revealing the URL the visitor was on — including its path and query string. If those URLs ever contain anything identifying (a search term, an internal path, a token in the query string), that information can leak to whatever third-party domain the link or resource points to.

The risk here is usually modest — it's metadata leakage, not credential theft — but browser default behavior for referrers isn't consistent across all situations, so setting an explicit Referrer-Policy (for example, strict-origin-when-cross-origin) makes the behavior intentional rather than incidental.

Response headers like Server and X-Powered-By can disclose exactly which web server and framework version you're running — for example Server: nginx/1.18.0. That specificity helps an attacker doing reconnaissance: known vulnerabilities are tied to exact versions, so this kind of header lets automated scanners prioritize targets running software with public CVEs.

Check your own response headers with curl -I and look for version numbers you don't need to expose. Most servers and reverse proxies let you suppress or generalize these headers in configuration. Worth being clear-eyed about what this buys you, though: hiding the version doesn't patch anything — it just raises the cost of casual, automated recon.

Mixed content happens when a page served over HTTPS still loads some of its resources — a script, a stylesheet, an image — over plain HTTP. Those individual requests aren't protected by TLS even though the page around them is, which means they can be tampered with in transit. Modern browsers block this outright for "active" content like scripts, and warn (or block) for "passive" content like images.

The fastest way to find it: open your browser's developer console on your live site and look for "Mixed Content" warnings, or search your page source for src="http:// and href="http:// references that should be HTTPS.

The Secure attribute on a cookie tells the browser to only ever send that cookie over an HTTPS connection — never over plain HTTP, even if someone ends up on an HTTP version of your site by accident. For session or authentication cookies, that matters: without Secure, a single HTTP request — an old link, a downgraded connection — could expose that cookie in cleartext.

You can see this directly in your browser's dev tools (Application → Cookies, check the Secure column), or from the command line:

curl -I https://yourdomain.com | grep -i set-cookie

Look for a ; Secure flag on each cookie in the response.

One clarification worth being precise about: the check this guide (and Nyrolo) covers here is specifically the Secure attribute. It does not check the HttpOnly or SameSite attributes, or your session-management logic more broadly — those are separate considerations, and a passing result here isn't a full cookie-security review.

HTTPS, a valid TLS certificate, and the right security headers form a genuinely important external layer — but a perfect score here doesn't mean a website is secure end to end. It says nothing about how authentication and authorization are implemented, whether the application itself has vulnerabilities, whether its dependencies carry known CVEs, how its infrastructure is configured, or whether backups exist and actually restore.

Those are all real, separate categories of security work — outside this checklist, and outside what Nyrolo's current scan checks for. Treat a clean result here as a solid baseline worth having before launch, not a finish line.