Website security basics: HTTPS, headers and scripts

On a public website, the first security step is to check what any visitor (or attacker) can see from the outside: whether every request ends up on HTTPS, whether the server accepts only TLS 1.2 and 1.3 with a valid certificate, whether the security headers are present, whether the page loads anything over HTTP, whether files such as .env, .git or backups are reachable, whether the CMS and plugins are up to date, which third-party scripts run on the page and how cookies are set. These items cover configuration and exposure. They do not tell you whether the code has flaws, whether passwords are stored properly or whether the admin panel holds up against attacks.

This guide applies to websites and online stores accessed through a browser, using the standards and recommendations in force in October 2026. Each section explains the item, how to check it and where to read more. The details of each header are in the article on HTTP security headers, and the rules for scripts on payment pages are in the article on PCI DSS 4.0 and requirements 6.4.3 and 11.6.1.

What an external check sees and what it misses

An external check sends requests to the site the way a browser would and analyzes the responses: HTTP status, redirects, headers, certificate, HTML and the resources the page requests. Mozilla's free HTTP Observatory works this way. Its own documentation says the test focuses on HTTP data and does not look for outdated software versions, SQL injection, vulnerable CMS plugins or improper password storage (HTTP Observatory FAQ).

So a high score in an external tool shows that the basic configuration protections are in place. It does not prove the site is secure. Mozilla gives the same warning: sites with a good score should not ignore the problems the tool does not test (HTTP Observatory FAQ).

One caveat before you start: reading headers and the certificate is what any browser does. Looking for hidden files or forcing old protocols is active testing, and you should only do it on sites you manage or with the owner's permission.

HTTPS and the redirect from http to https

HTTPS is HTTP inside a connection encrypted with TLS (Transport Layer Security), the protocol that protects data between the browser and the server. The whole site should respond over HTTPS, and anyone who arrives via http:// should be redirected to the same address on https://. Mozilla's guidance is that, on port 80, the server should only redirect to the same resource over HTTPS. If the final domain is different (for example, without and with www), the first hop should go to HTTPS on the same host, and only then to the other host (MDN: TLS practical guide). The HTTP Observatory penalizes the case where the first hop already changes host (HTTP Observatory FAQ).

To check from the terminal, request only the headers of the http version:

curl -sI http://example.com/

The expected response is a 301 or 308 with Location: https://example.com/. A 200 on http means the site still serves unencrypted content. APIs and areas that are not meant for the public can simply turn HTTP off (MDN: TLS practical guide). Long redirect chains also slow the page down; the article on redirects, chains and loops covers that side.

TLS version and certificate validity

The IETF deprecated TLS 1.0 and TLS 1.1 in 2021: RFC 8996 says neither should be used or negotiated (RFC 8996). OWASP ASVS 5.0, the application security verification standard, requires that only the recommended versions be enabled, such as TLS 1.2 and TLS 1.3, with the newest one preferred (ASVS 5.0, requirement 12.1.1), and that exposed services use certificates issued by publicly trusted authorities (requirement 12.2.2).

To see whether the server still accepts TLS 1.1 and when the certificate expires, OpenSSL does the job:

# should fail if TLS 1.1 is disabled
openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null

# certificate start and end dates
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

Certificate lifetimes are getting shorter. In April 2025 the CA/Browser Forum, which brings together certificate authorities and browser makers, approved a gradual reduction of the maximum validity from 398 to 47 days, between March 2026 and March 2029 (Ballot SC-081v3). According to the schedule published by DigiCert, the limit is 200 days for certificates issued from March 15, 2026, 100 days from March 15, 2027 and 47 days from March 15, 2029 (DigiCert). With lifetimes like these, manual renewal becomes a risk of the site going down over an expired certificate. Recommendation: automate renewal and set up an independent alert for expiry.

HSTS

The redirect alone leaves a gap: the first request over http still travels unencrypted. The Strict-Transport-Security (HSTS) header tells the browser to use only HTTPS on that domain for the time set in max-age, and the browser then converts http links on its own and stops the user from bypassing certificate errors (MDN: Strict-Transport-Security). ASVS requires a max-age of at least one year (ASVS 5.0, requirement 3.4.1). Before including subdomains or applying for the browsers' preload list, make sure every subdomain works over HTTPS; the details are in the article on HTTP security headers.

Security headers at a glance

HTTP response headers tell the browser what it may do with the page: where to load scripts from, whether the page can be shown inside another one, what information to send to other sites. They do not fix flaws in the code, but they limit what an attacker can do with them. The table sums up the main ones.

Mozilla maintains practical guides for each item, in a suggested order of rollout based on impact and difficulty, and the HTTP Observatory links to the guide for each problem it finds (MDN: practical security guides). ASVS 5.0 also lists these headers among its front-end requirements (ASVS 5.0, chapter V3). Recommended values, examples and what each one can break are in the article on HTTP security headers.

Mixed content

Mixed content is when a page loaded over HTTPS requests resources over HTTP. Those resources can be read or altered in transit. Current browsers upgrade images, audio and video requested over http to HTTPS and block the other types, such as scripts, stylesheets, iframes, fonts and fetch() calls (MDN: mixed content). In practice, the most common symptom is a part of the page that disappears or stops working with no visible error.

To find it, open the browser console: mixed content warnings show up there. The fix is to change the addresses to https or to relative paths. The CSP directive upgrade-insecure-requests makes the browser upgrade these requests to HTTPS, but it does not replace HSTS and only works if the resource exists over HTTPS (MDN: CSP guide). In a CMS, the http addresses are usually stored in the database, in old posts or in the theme settings.

Exposed files and directory listing

A site can unintentionally expose files that should not be in the public folder: copies such as login.php.old, .zip or .tar.gz backup files, automatic editor copies (such as file~), configuration files and version control folders. The OWASP testing guide records this problem (WSTG-CONF-04) and explains the risk: a copy with a different extension may be served as text, revealing the source code and sometimes database credentials (OWASP WSTG, WSTG-CONF-04). robots.txt does not hide these files: it only asks crawlers not to crawl a path, and anyone can read it (RFC 9309).

ASVS 5.0 has requirements that address this directly (ASVS 5.0, section V13.4):

• The application is deployed to production without version control metadata, such as the .git and .svn folders, or with those folders made inaccessible (13.4.1).

• The server does not show directory listings, the automatic page with the files in a folder, unless that is intended (13.4.3).

• The server only serves files with specific extensions, so configuration and source code do not leak (13.4.7).

The .env file deserves its own mention: many frameworks use that name to store database passwords, API keys and other secrets in plain text. It should live outside the public folder. On your own site, a quick check is to request these paths and look at the status:

for p in .env .git/HEAD backup.zip wp-config.php.bak; do
  printf '%s ' "$p"; curl -s -o /dev/null -w '%{http_code}\n' "https://example.com/$p"
done

The expected result is 403 or 404. Watch out for sites that answer 200 for any address with their own error page: in that case, check the content returned, not just the status. The list above is a starting point, not a complete inventory; backup file names vary with the plugin or the hosting control panel.

Software versions, CMS and plugins

Outdated components are still among OWASP's central risks. In the 2025 Top 10, category A03, software supply chain failures, broadens the old category of vulnerable and outdated components and includes failing to track the versions of everything you use, on the server and in the browser (OWASP Top 10:2025, A03). The recommendations include keeping an inventory of components, removing unused dependencies and features, getting components only from official sources and applying fixes according to risk, without waiting for a monthly or quarterly cycle.

For a CMS site, this means updating the core, theme and plugins, deleting deactivated plugins (deactivated code is still on the server) and following vendors' security advisories. From the outside, a check can only see the version the site announces, in headers such as Server and X-Powered-By or in HTML meta tags. OWASP recommends removing these headers (OWASP Secure Headers Project, list of headers to remove), and ASVS points out that hiding the version does not remove the need to update (ASVS 5.0, section V13.4). In other words, not seeing the version from outside does not mean it is up to date.

Third-party scripts as a supply chain risk

Every script loaded from another domain (chat, analytics, ad pixel, tag manager, review widget) runs with the same permissions as the site's own scripts. If the vendor is compromised or swaps the file, the new code runs on your page without any change on your server. PCI DSS describes this risk in the guidance for requirement 6.4.3: seemingly harmless scripts can be used to load malicious code that reads card data and sends it out (PCI DSS v4.0.1, requirement 6.4.3).

There are three basic measures. The first is an inventory: which scripts each page loads, from where and why. The second is to verify integrity where possible: the integrity attribute (SRI, Subresource Integrity) makes the browser reject a file whose content does not match the declared hash, and ASVS requires SRI for static, versioned resources hosted elsewhere (ASVS 5.0, requirement 3.6.1; MDN: SRI). The third is to limit origins with a CSP. SRI does not work for scripts the vendor updates without changing the address, and that is where inventory and monitoring come in. On payment pages this is no longer just good practice: see the article on PCI DSS requirements 6.4.3 and 11.6.1. The same scripts also send visitor data to third parties, which in Brazil falls under the LGPD (Lei Geral de Proteção de Dados, Brazil's data protection law), the subject of the article on third-party pixels and scripts.

Forms and cookies

Contact, login and checkout forms should be served and submitted over HTTPS. A form on an HTTPS page that submits to an http address exposes the data in transit.

Session and login cookies need three attributes (MDN: Set-Cookie):

Without SameSite, some browsers apply Lax by default, in a slightly more permissive way than an explicit Lax (MDN: Set-Cookie; web.dev: SameSite cookies explained). The safest option is to declare the value. ASVS 5.0 goes further and asks for the __Host- or __Secure- prefixes in cookie names, which make the browser reject the cookie if it lacks Secure and, for __Host-, if it has a Domain attribute or a path other than / (ASVS 5.0, requirements 3.3.1 to 3.3.4).

To check, open the DevTools cookies panel (the Application tab in Chrome) after logging in and look at the Secure, HttpOnly and SameSite columns for each cookie. Cookies from third-party tools are set by those tools, and you cannot always change their attributes.

Where to start

A practical order, from the simplest and most effective to the most work, based on the sequence of Mozilla's guides (MDN: practical security guides). It is a recommendation, not a rule; an online store with its own checkout should move the scripts step earlier.

1. Serve every page over HTTPS, with the redirect from http to https on the same host.

2. Turn off TLS 1.0 and 1.1 and automate certificate renewal, with an expiry alert.

3. Find and remove exposed files (.env, .git, backups) and turn off directory listing.

4. Update the CMS, theme and plugins and delete what is not used.

5. Fix mixed content and enable HSTS, starting with a short max-age.

6. Review the attributes of session cookies.

7. Add the simple headers (nosniff, Referrer-Policy, frame-ancestors) and start CSP in report-only mode.

8. Take an inventory of third-party scripts and cut the ones that have no reason to be there.

How to check your site

For headers and redirects, Mozilla's HTTP Observatory is free and explains each item. At WebVyze, the free redirect checker shows the chain of hops for a URL; test it with the http:// address to see whether the first hop goes to HTTPS on the same host. The WebVyze audit, which the free plan runs once every 30 days, checks HTTPS, TLS certificate validity, HSTS, whether the page can be embedded by other sites, whether a CSP is present and effective, the Secure, HttpOnly and SameSite attributes of cookies, the integrity attribute on public CDN libraries, X-Content-Type-Options, Referrer-Policy, software versions exposed by the server and plugins or themes with known vulnerabilities. For stores, the paid plans keep an inventory of scripts on checkout pages, tied to PCI DSS 4.0 requirements 6.4.3 and 11.6.1. WebVyze only reads public pages and never changes the site, so it sees what is in the table in the first section and nothing more. None of these tools replaces a penetration test or a code review.