A website security audit checklist for businesses is a structured list of the issues that most often lead to hacked websites, defaced pages, spoofed company emails and leaked customer data, with how to check each one. Most of these checks need no special tools: a browser, access to your domain and hosting accounts, and an hour or two with whoever manages your website.
Work through the eleven areas below, note what fails, and fix the highest-risk items first. If you would rather have an independent team do this, and test beyond a checklist, see our website security audit service.
Before You Start
Collect logins for the domain registrar, DNS, hosting panel, CMS, email admin and tag manager, and note who owns each account. If the answer is a former employee or an agency you no longer use, that is your first finding. Test only websites you own, and try anything that changes data on a staging copy first.
Website Security Audit Checklist for Businesses: 11 Areas
1. Domain and DNS
- The domain is registered to the company, in a company-controlled account. How to check: log in to the registrar and confirm the account owner and contact email.
- Auto-renew and registrar lock are on, and the registrar login uses two-factor authentication. How to check: the domain settings page at your registrar.
- No dangling DNS records. Old subdomains pointing to deleted hosting or cloud services can be taken over. How to check: export the DNS zone and confirm every record points to something you still use.
- SPF is correct: a single SPF record listing every service that sends email for your domain. How to check: look up your domain's TXT records with any online DNS lookup tool.
- DKIM is enabled for your email provider and every service that sends on your behalf, such as your CRM or billing software. How to check: send a test email to a Gmail account and use Show original to see the SPF, DKIM and DMARC results.
- DMARC is published and moving towards enforcement. Start with p=none and reports, then quarantine, then reject once all legitimate senders pass. How to check: look up the TXT record at _dmarc on your domain.
2. HTTPS, TLS and security headers
- Every hostname has a valid certificate that renews automatically, including www and subdomains. How to check: click the padlock in the browser and note the expiry date.
- HTTP always redirects to HTTPS, and only TLS 1.2 and 1.3 are enabled. How to check: type the http:// version of your URLs, and run a free online TLS test such as SSL Labs.
- Security headers are present. How to check: in browser developer tools, read the response headers of the page request in the Network tab. The OWASP Secure Headers Project explains each one in detail.
- Cookies are flagged correctly: session cookies should have the Secure, HttpOnly and SameSite attributes. How to check: the Application or Storage tab in developer tools.
| Header | What it does | Typical setting |
|---|---|---|
| Strict-Transport-Security | Tells browsers to use HTTPS only | max-age of at least six months; add includeSubDomains once every subdomain uses HTTPS |
| Content-Security-Policy | Limits which scripts and resources can load, reducing the impact of cross-site scripting | Start in report-only mode, then enforce |
| X-Content-Type-Options | Stops browsers guessing file types | nosniff |
| X-Frame-Options or CSP frame-ancestors | Stops other sites framing your pages for clickjacking | DENY or SAMEORIGIN |
| Referrer-Policy | Controls how much URL information is shared with other sites | strict-origin-when-cross-origin |
| Permissions-Policy | Turns off browser features you do not use, such as camera or microphone | Disable unused features |
3. CMS, plugins and updates
- Core software, themes and plugins are current. How to check: the updates screen in your CMS; for custom sites, ask your developer.
- Unused plugins and themes are deleted, not just deactivated. How to check: the plugin and theme lists.
- No abandoned or pirated plugins or themes. Nulled software often contains backdoors. How to check: confirm the source and last update date of each plugin.
- The server runs a supported PHP version. How to check: your hosting control panel.
- The built-in code editor in the CMS admin is disabled, so a stolen admin password cannot change code. How to check: look for a theme or plugin file editor in the admin menu.
4. Authentication and admin access
- Every person has their own account, with no shared admin logins, and former employees, agencies and freelancers have been removed. How to check: review the user lists in the CMS, hosting panel, registrar and email admin.
- Two-factor authentication is on for CMS admins, hosting, the domain registrar, email and any payment or analytics accounts. How to check: the security settings of each account.
- Login attempts are rate limited or locked after repeated failures. How to check: on your own test account, enter a wrong password ten times and see what happens.
- Password reset does not reveal whether an account exists, and reset links expire. How to check: request resets for a real and a made-up email address and compare the messages.
- Admin areas are restricted by IP address or VPN where practical. How to check: try opening the admin URL from a mobile network.
5. Forms and input handling
- Contact, enquiry and OTP forms are protected from abuse with rate limits or a CAPTCHA. Unprotected OTP forms can be abused to send thousands of paid SMS messages at your cost. How to check: submit a form several times quickly and see whether anything stops you.
- Input is validated on the server, not only in the browser. How to check: ask your developer; custom code should use parameterised database queries and encode output.
- Errors do not reveal technical details. How to check: type a single quote (') into your site's search box and forms. You should see a normal message, not a database error or stack trace.
- Forms that change data have CSRF protection. How to check: ask your developer; most frameworks include it, but it can be switched off.
6. File uploads
- Only expected file types are accepted, checked by an allow-list on the server and not only by file extension. How to check: on a staging copy, try uploading a text file renamed to .jpg.
- Uploaded files cannot run as code. How to check: ask your developer or host to confirm that script execution is disabled for the upload folder.
- Private uploads are not publicly reachable. Resumes, KYC documents and invoices should never sit at guessable URLs. How to check: open an uploaded document's link in a private window while logged out.
- File size limits are set, and uploaded files are renamed on the server.
7. Backups and restore test
- Files and database are backed up automatically, at least daily for sites that change often. How to check: the date of the last successful backup in your hosting panel.
- At least one copy is kept off the server, in a separate account that the website admin cannot delete. How to check: find where the copies actually live.
- No backups sit in the public web folder. How to check: look in the web root for .zip, .sql, .bak or .tar files and move them out.
- A restore has been tested in the last three months, and you know how long it takes. How to check: restore the latest backup to a staging site and confirm it works.
8. Hosting and server
- The hosting control panel uses two-factor authentication and has only named users. How to check: the panel's user and security settings.
- Only necessary ports are open to the internet, usually 80 and 443. SSH or remote desktop is restricted and uses keys or strong authentication. How to check: ask your host, or run a port scan against your own server's IP address.
- Sensitive files are not reachable. How to check: in a browser, add /.env and /.git/HEAD to your domain; both should return not found or forbidden.
- Directory listing is off. How to check: open a folder URL such as /uploads/ and confirm you do not see a list of files.
- The operating system and web server get security updates. How to check: confirm your host's patching policy, or review the update history on your own server.
9. Logging and monitoring
- Web server access and error logs are kept, along with CMS admin activity logs. CERT-In's 2022 directions require organisations to keep logs of their ICT systems for 180 days, within India. How to check: ask your host how long logs are retained and where.
- Someone is alerted to admin logins, new admin users, file changes and downtime, by email or WhatsApp. How to check: trigger a test alert and see who receives it.
- You know who reports an incident. CERT-In requires specified cyber incidents to be reported within six hours of noticing them. Write down who does this and how; reporting details are on the CERT-In website.
10. Third-party scripts
- You have a list of every external script on the site: analytics, chat widgets, ad pixels, fonts and payment widgets. How to check: in developer tools, open the Network tab, filter by JS and note each domain.
- Unused scripts are removed. Any script on a page can read what users type on that page.
- Tag manager access is limited to named people, because anyone with access can add a script to every page.
- Payment and login pages carry as few third-party scripts as possible.
11. Privacy and DPDP basics
- A clear privacy notice explains what personal data you collect, why, and how people can contact you about it. How to check: compare it with what your forms actually collect.
- Forms collect only what you need. If you do not use date of birth, do not ask for it.
- Marketing consent is not pre-ticked and is kept separate from the main enquiry.
- Form submissions are stored securely and deleted when no longer needed, and vendors that handle them are covered by contracts.
For what the DPDP Act, 2023 expects in practice, see our guide to DPDP Act compliance.
When a Checklist Is Not Enough
A checklist catches hygiene problems such as missing updates, weak settings and forgotten accounts. It does not find flaws in how your application behaves, which is where serious breaches usually begin. It will not tell you whether:
- a logged-in customer can view another customer's orders or invoices by changing a number in the URL;
- prices, discounts or payment amounts can be altered in the request before it reaches your server;
- your APIs return more personal data than the screen shows;
- an attacker can chain two low-risk issues into a serious one.
Book a professional audit or VAPT when your website has a login or customer portal, takes payments or stores personal data; after a redesign or hosting move; after any security incident; or when a client, auditor or regulator asks for a report. Our guide on what VAPT is and why businesses need it explains the difference between a scan and a real test.
EthicsComputer's company security audit starts at ₹25,000 + 18% GST for one website or web application plus a core server check. Testing is manual-first, findings are CVSS-rated with remediation guidance for your developers, and one re-test is included free.
FAQs
What should a website security audit checklist include?
It should cover domain and email authentication (SPF, DKIM and DMARC), HTTPS and security headers, software updates, admin access with two-factor login, forms and file uploads, backups with a tested restore, hosting, logging, third-party scripts and basic privacy practices.
How often should a business audit its website security?
Run a self-check like this every quarter and after any significant change, such as a new plugin, a new form, a hosting move or a change of developer. Add a professional audit or VAPT and a full restore test at least once a year, and test before launching features that handle logins, payments or personal data.
Can I do a website security audit myself?
You can check most hygiene items yourself with a browser and access to your hosting, domain and CMS accounts. What a self-audit cannot reliably find are application flaws, such as one customer seeing another customer's data or prices being changed before they reach the server. Those need manual testing by experienced testers.
What is the difference between a website security audit and VAPT?
A website security audit usually reviews configuration and hygiene: updates, accounts, headers, DNS, backups and hosting. VAPT adds vulnerability scanning and manual penetration testing to find and prove exploitable flaws in the application itself. Many businesses combine both in one engagement.
How much does a professional website security audit cost?
It depends on the size of the site, whether it has logins, payments or APIs, and which servers are in scope. EthicsComputer's company security audit starts at ₹25,000 plus 18% GST for one website or web application plus a core server check, with the final quote after scoping.
If your website collects enquiries, payments or customer data, an independent check is the sensible next step after this checklist. Explore our website security audit service, or contact us to sign an NDA and scope a test. You can also WhatsApp us on +91 90532 10052.
