Beginner's Guide to Fixing Website Security

If your Security Audit came back with red FAIL marks and you have no idea what to do next, this guide is for you. No jargon, no command-line wizardry, no assumptions about what you know. We will walk through the most common failures, explain what each one means in plain English, and tell you exactly what to do — or exactly what to ask your hosting provider to do for you.

Before you start: three things to know

1. A failed security check does not mean you have been hacked. It means a door is unlocked that should be locked. Fixing it makes your site harder to attack tomorrow.

2. You do not need to be a developer. Most fixes are either a toggle in your hosting control panel, a copy-paste into a settings file, or a one-line request to your hosting provider's support team.

3. You do not have to fix every finding to be safer. The five fixes below cover 80% of typical audit failures and take an afternoon at most.

Fix 1: Missing security headers

If the audit shows red marks for things called Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy or Permissions-Policy, these are missing security headers.

Headers are short instructions your website sends to every visitor's browser. The browser obeys them — for example, "do not let other websites embed me in a frame" or "only connect to me over HTTPS." Without these instructions, the browser uses default behaviour that is more permissive than it should be.

Fix 2: The X-Powered-By header is leaking

This header tells anyone who asks exactly what software your site runs on. For example: X-Powered-By: PHP/7.4.0. Attackers scan the web for this header to find sites running specific software versions with known weaknesses. It is the digital equivalent of having your alarm system's brand on the front door.

Fix 3: TLS or HTTPS warnings

TLS is the technology behind the padlock icon in your browser's address bar. The audit checks three things: your certificate is valid, it is not about to expire, and your server is using a modern version of TLS.

Most modern hosting handles this for you. If you see a TLS warning, the most common causes are:

• Certificate expiring soon: your hosting normally renews automatically. If the renewal is broken, your provider will know how to fix it.
• Old TLS version (1.0 or 1.1) still enabled: only happens on older servers. Your hosting provider can disable old versions for you.
• Self-signed certificate: free, trusted certificates are available everywhere (Let's Encrypt). Switch from self-signed to a real one.

Fix 4: No security.txt file

security.txt is a tiny text file that tells security researchers how to contact you if they find a problem with your website. Without it, a researcher who finds a serious bug has no obvious way to tell you — and may resort to making it public instead.

It is one of the simplest fixes on the entire list. Create a plain text file with these four lines (change the email and date):

Contact: mailto:security@yourdomain.com
Expires: 2027-12-31T23:59:59.000Z
Preferred-Languages: en
Canonical: https://yourdomain.com/.well-known/security.txt

Upload it to your website at the path /.well-known/security.txt. Most hosting file managers let you create folders and files directly — create a folder named .well-known (yes, with the leading dot) in your site root, then upload the file inside it.

Fix 5: Mail security DNS records (SPF, DKIM, DMARC)

Even if your website does not send email, attackers can still send phishing emails pretending to come from your domain. Three DNS records prevent this:

• SPF: a list of servers allowed to send email as you
• DKIM: a cryptographic signature on your real emails
• DMARC: tells receiving mail servers what to do with unsigned mail (reject it, mostly)

If you use Google Workspace, Microsoft 365, or another mainstream email provider, they publish step-by-step instructions for adding SPF, DKIM and DMARC records to your DNS. The records go where your domain's DNS is hosted — usually your domain registrar (GoDaddy, Namecheap, etc.) or your hosting control panel.

What you can safely ignore

Not every audit finding is equally important. If you are short on time, these are lower priority:

• Cookie security flags if your site does not set login cookies (e.g. a static brochure site with no user accounts)
• CMS version exposure warnings if you keep your CMS updated automatically — the version leak only matters if you are running outdated software
• Verbose Server header warnings if everything else passes — this is the lowest-impact fingerprinting issue

Glossary

Header

A short instruction your website sends to every visitor's browser, separately from the page content. Headers tell the browser things like "be careful with this content" or "always use HTTPS for me."

HTTPS / SSL / TLS

The technology behind the padlock icon. Encrypts the connection between visitor and website so nobody in the middle can read it. SSL is the old name; TLS is the modern version. People say "SSL" but usually mean TLS.

CMS (Content Management System)

The software you use to manage your website's content. WordPress, Joomla, Drupal, Shopify, Squarespace and Wix are all CMSes.

DNS

The address book of the internet. DNS translates your domain name into the numerical IP address of the server. DNS records also store things like email-sending permissions.

Fingerprinting

When your website tells anyone who asks exactly what software it runs and what version. Helpful for support, dangerous for security. Best practice is to hide the version, like an unlabelled box of expensive equipment.

XSS (Cross-Site Scripting)

An attack where someone injects malicious JavaScript into your website's pages. Security headers like Content-Security-Policy stop most XSS attacks before they start.

CSRF (Cross-Site Request Forgery)

An attack where one website tricks a user into doing something on a different site they are logged into. The SameSite cookie flag stops most CSRF.

Ready for more detail?

Each fix above has a more thorough guide if you want to understand what is actually happening:

• Complete Security Audit Guide — the full reference for every check
• Expert Reference — dense, command-line oriented
• How to fix in Plesk — server-specific walkthrough
• How to fix in WordPress — CMS-specific walkthrough