The security of your website does not begin with firewalls and penetration tests. It begins with the basics: are the fundamental security mechanisms configured correctly? In practice, we see that most websites already have shortcomings at this level. Not through negligence, but through a lack of insight. This article describes step by step how you can check and improve the security of your website.
Step 1: SSL/TLS configuration
Having an SSL certificate is not enough. The configuration behind it determines whether the connection is actually secure. Check whether your server does not support outdated protocols. TLS 1.0 and 1.1 have been officially discouraged since 2021 and are no longer supported by modern browsers. Yet we still encounter them regularly, especially on older web servers and applications.
Also check whether your certificate chain is complete. An incomplete chain leads to warnings in some browsers and can cause automated systems to classify your site as insecure. The cipher suites your server offers must contain modern, secure options and exclude weak ciphers.
Step 2: Security headers
Security headers are instructions that your web server sends along with every response. They tell the browser how to handle the content. The most important headers are Content-Security-Policy (CSP), which dictates which resources the browser is allowed to load. A good CSP prevents cross-site scripting by restricting which scripts may be executed. Strict-Transport-Security (HSTS) enforces that the browser always uses HTTPS, even if a user accidentally types HTTP. X-Content-Type-Options prevents the browser from interpreting files differently than intended. X-Frame-Options, or the more modern frame-ancestors directive in CSP, protects against clickjacking.
Adding these headers is technically simple. In most web servers and frameworks it is a matter of configuration. The impact on security is disproportionately large relative to the effort.
Step 3: Email security
Your website and your email share the same domain. If your email security is not in order, attackers can send emails that appear to come from your organisation. This is not hypothetical; email spoofing is one of the most common attack techniques.
SPF (Sender Policy Framework) specifies which mail servers are allowed to send on behalf of your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails. DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving mail servers what to do with emails that fail SPF or DKIM checks.
The ideal configuration is a DMARC policy set to reject: emails that do not pass the checks are refused. Many organisations start with a policy set to none (reporting only) and tighten it gradually once they have insight into their email flows.
Step 4: DNS security
DNS is the address book of the internet, and it is surprisingly often unprotected. DNSSEC adds cryptographic verification to DNS responses, thereby preventing manipulation. CAA records specify which certificate authorities may issue certificates for your domain, a simple measure that prevents an attacker from obtaining a fraudulent certificate.
Also check whether your DNS server does not allow zone transfers to arbitrary IP addresses. A zone transfer reveals your complete DNS configuration, including all subdomains, which is valuable information for an attacker.
Step 5: Forgotten subdomains
Subdomains are an underestimated attack surface. Organisations create subdomains for test environments, campaigns and old applications, and then forget about them. These subdomains often run on outdated software without updates and without monitoring. Through Certificate Transparency logs, it is possible for anyone to see which subdomains exist under your domain.
Make an inventory of all active subdomains and remove or secure those that are no longer needed. This is one of the fastest ways to reduce your attack surface.
Step 6: Cookies and tracking
Check which cookies your website places and whether they have the right security flags. HttpOnly prevents JavaScript from accessing the cookie, which protects against theft via XSS. Secure ensures the cookie is only sent over HTTPS. SameSite restricts sending cookies with cross-site requests, which protects against CSRF attacks.
In addition, check whether your cookie policy matches your privacy statement and whether you comply with the GDPR requirements for tracking cookies.
Automate the check
Carrying out all these checks manually is time-consuming. That is why we built ScanZeker.nl: a free tool that checks all these aspects in a single scan. Enter your domain and within a minute you receive an overview of all findings with concrete recommendations for each component. No account needed, no cookies, fully privacy-friendly.
For organisations that want a more in-depth assessment, Secure Audit offers technical security assessments and IT audits. An external scan shows the exterior; an audit also assesses the internal configuration, processes and governance.
Get in touch to discuss how we can help your organisation improve your website security.
About the author
Partner | IT Auditor