A website security checklist is only useful if it tells you what to do before the site goes live and what to keep doing once it is public. Most lists skip that split, which is how launches end up with default passwords, a public staging site and nobody watching the logs. This guide gives you 20 checks, ten for before launch and ten for after, with a plain way to confirm each one is done and a note on who should do it. Security is one part of the wider picture in our web development guide, so treat this page as the deep dive for protection. It is written for owners and decision-makers who commission websites and web apps, not for security specialists.
Quick answer: Before launch, enforce HTTPS, set security headers, validate every input, protect sessions, lock down logins and permissions, keep secrets out of code, scan dependencies, secure your APIs and test everything. After launch, patch on a schedule, test your backups, add a firewall, scan for malware, monitor logs, review access, manage certificates and domains, audit regularly, plan for incidents and keep compliance current.
Who Is Responsible for Website Security?
The short answer is that everyone involved owns a piece, and trouble starts in the gaps between them. A development team can build a solid login system, but if the owner never removes a former employee's admin account, the door stays open.
| Party | Usually owns | Ask them for |
| Business owner | Admin accounts, user access, domain and registrar logins, compliance decisions, budget | Current user list, registrar details, renewal dates |
| Development team | Secure code, authentication, API design, dependencies, testing, deployment | Test summary, scan reports, update plan |
| Hosting provider | Server hardening, network firewall, platform patches, infrastructure backups | Backup policy, firewall coverage, uptime record |
Put these roles in writing before the project starts. Decide who patches, who monitors and who responds when something breaks. If you are hiring a web application development team, ask them to confirm in the proposal which of the checks below they handle and which stay with you.
How to Use This Website Security Checklist
Every check carries two tags. Priority is Critical, Important or Good practice. Owner is Owner, Developer or Shared. Start with the Critical items, because those are the ones attackers find first.
The number of Critical checks grows with the complexity of what you run. A brochure site with a contact form has a small attack surface. A customer portal with logins, payments or stored personal data has a large one. If your project includes any of those, treat it as a web application, and read how a website differs from a web application before you decide how much testing to buy.
Each check ends with a short "How to verify" line. You do not need to be technical to use it. You only need to ask for the evidence.
Before Launch: 10 Security Checks
These ten checks belong in your launch gate. If a check fails, fix it before the site is public.
1. Enforce HTTPS Everywhere With HSTS
Priority: Critical | Owner: Developer
HTTPS encrypts traffic between visitors and your server, and it is the baseline for any site that handles logins or forms. Redirect every HTTP request to HTTPS, use a current TLS version and add the Strict-Transport-Security header so browsers refuse to connect over plain HTTP in the future. A padlock alone does not make a site secure, but its absence makes every other check pointless.
How to verify: Type your address with http:// and confirm it redirects. Run the domain through a free SSL test and look for a clean grade.
2. Set Security Headers
Priority: Important | Owner: Developer
Security headers tell the browser how to treat your pages. A Content Security Policy limits which scripts can run, which blunts many cross-site scripting attacks. Other headers stop your pages from being framed by other sites, stop browsers from guessing file types and control what referrer data you leak. They are cheap to add and often forgotten.
How to verify: Run your domain through a free security headers checker and review anything marked missing.
3. Validate Every Input and Encode Every Output
Priority: Critical | Owner: Developer
Any field a visitor can type into is a possible attack route. SQL injection and cross-site scripting both start with the application trusting input it should have checked. Validation has to happen on the server, because checks that live only in the browser are easy to bypass. This is the kind of work that sits in back-end development, so ask your team how they validate input and encode output at every point where user data is stored or displayed.
How to verify: Ask for the validation approach in writing and for a scan or code review result that covers injection and scripting flaws.
4. Protect Sessions With CSRF Tokens and Secure Cookies
Priority: Important | Owner: Developer
Once someone logs in, the site tracks them with a session cookie. If that cookie can be read by scripts or sent over an insecure connection, it can be stolen. Mark session cookies as Secure, HttpOnly and SameSite, and add CSRF protection so another site cannot trick a logged-in user into submitting an action they never meant to take.
How to verify: Open your browser's developer tools, look at the cookies and check the flags on the session cookie.
5. Lock Down Logins
Priority: Critical | Owner: Shared
Weak authentication is still one of the easiest ways in. Require strong passwords, add multi-factor authentication for admins and for any account that can see sensitive data, and limit repeated failed attempts so brute-force tools get nowhere. Store passwords with a modern hashing method, never in plain text. As the owner, your part is to use the protections you are given and never share one admin login across a team.
How to verify: Try a weak password, then try several wrong passwords in a row, and confirm the system blocks or slows you down.
6. Apply Least Privilege and Role-Based Access Control
Priority: Critical | Owner: Developer
Every user should see and do only what their role needs. Broken access control sits at the top of the OWASP Top 10, and it often looks mundane: a customer who changes a number in a web address and sees another customer's invoice. Define roles early, enforce them on the server for every request and keep admin functions on a separate, protected path.
How to verify: Log in as an ordinary user and try to open admin pages and other users' records. Both should be refused.
7. Keep Secrets and Configuration Clean
Priority: Critical | Owner: Developer
API keys, database passwords and tokens do not belong in source code or public repositories. Store them in environment variables or a secrets manager, use different values for staging and production, and turn off debug mode before launch. Detailed error pages that show file paths or database details are a gift to attackers.
How to verify: Ask the team to confirm that no secrets are in the repository history and that production has debug output disabled.
8. Scan Dependencies for Known Vulnerabilities
Priority: Important | Owner: Developer
Modern sites are built from many third-party packages, and each one can carry a published flaw. Scan your dependency list before launch, remove packages you do not use and lock versions so builds are repeatable. The framework and library choices behind your project matter here, which is why it helps to understand the technologies top web development companies use and how actively each one is maintained.
How to verify: Request the dependency scan report and the plan for fixing anything it flags.
9. Secure Your APIs
Priority: Critical | Owner: Developer
If your site or app talks to a back end through an API, every endpoint needs its own protection. Require authentication on each one, check permissions per request, validate the shape of incoming data, limit request rates and return only the fields the client needs. Mobile apps that share the same back end inherit the same risks, so the guidance in our mobile app security article applies to the client side of the same system.
How to verify: Ask for an endpoint list showing the access rule for each one, and confirm that unauthenticated requests are rejected.
10. Test Before You Ship
Priority: Critical | Owner: Shared
Run an automated vulnerability scan on the finished build, and add a manual test or a penetration test if the product handles payments, personal data or health records. Block your staging site from search engines and from the public, and restrict file uploads by type and size. Security testing is strongest when it is part of the delivery process rather than a last-minute step, which is how the stages in a custom software development guide are normally laid out.
How to verify: Ask for the test summary and the list of open findings, each with an owner and a date.
After Launch: 10 Security Checks
Launch day is the start of the work. These checks keep the site safe as software ages, staff change and attackers adapt.
11. Patch on a Schedule
Priority: Critical | Owner: Shared
Unpatched software is a leading way sites get compromised, because attackers scan the web for known flaws the moment they are published. Agree a monthly update cycle for the CMS, framework, libraries and server operating system, with faster handling for urgent fixes. Test updates on staging first so a patch does not break checkout.
How to verify: Ask for the update log showing dates and versions.
12. Back Up Using the 3-2-1 Rule and Test the Restore
Priority: Critical | Owner: Shared
Keep three copies of your data, on two different types of storage, with one copy offsite. A backup you have never restored is a hope, not a plan. Decide how much data you can afford to lose and how long you can be offline, then check that your backup schedule and restore time fit those limits.
How to verify: Request the result of a recent restore test, not just proof that backups ran.
13. Add a Web Application Firewall and DDoS Protection
Priority: Important | Owner: Developer or host
A web application firewall filters malicious traffic before it reaches your application, and DDoS protection absorbs floods designed to knock you offline. Neither replaces secure code, but both reduce the noise and buy you time when something new appears.
How to verify: Confirm which provider and rule set you use, and check whether blocked requests are logged.
14. Scan for Malware and Watch File Changes
Priority: Important | Owner: Developer or host
Scheduled malware scans and file integrity monitoring tell you when something on the server changes without a deployment behind it. Early detection turns a long clean-up into a short one.
How to verify: Ask to see the scan schedule and the most recent report.
15. Log, Monitor and Alert
Priority: Important | Owner: Shared
Logs are only useful if someone reads them. Track failed logins, unusual traffic, server errors and changes to admin accounts, and send alerts to a named person. If you have no engineers to watch this, bringing in dedicated DevOps or security capacity through IT staff augmentation is often quicker than hiring a full team.
How to verify: Trigger a test alert and confirm it reaches the right person.
16. Review Access Every Quarter
Priority: Critical | Owner: Owner
People leave, agencies rotate and contractors finish. Every account they held stays active until someone removes it. List everyone with admin, hosting, code repository and analytics access every quarter, remove what is no longer needed and confirm multi-factor authentication is on for the rest.
How to verify: Compare the user list against your current team and vendors.
17. Manage Certificates, Domains and DNS
Priority: Important | Owner: Owner
An expired certificate throws a browser warning, and a hijacked domain can redirect every visitor. Turn on automatic certificate renewal, lock the domain at the registrar, protect the registrar account with multi-factor authentication and keep DNS access limited to people who need it.
How to verify: Check expiry dates for the certificate and the domain, and confirm who can change DNS records.
18. Schedule Regular Audits
Priority: Important | Owner: Shared
Run a vulnerability scan every quarter and a penetration test at least once a year for anything handling sensitive data. Repeat the scan after major releases or infrastructure changes. A vulnerability scan is automated and finds known weaknesses. A penetration test is a manual attempt to break in and finds what the tools miss.
How to verify: Keep dated reports and track each finding to closure.
19. Write an Incident Response Plan
Priority: Critical | Owner: Shared
Decide in advance who leads when something goes wrong, who talks to customers, how you roll back to a clean version and when you must notify regulators or affected users. A one-page plan that people have actually read beats a long document nobody opens. When you evaluate vendors, ask how they handle incidents, since it tells you a lot about how they work, and our notes on how to choose a web development company cover what to look for.
How to verify: Walk through the plan once a year with a simple scenario, such as a compromised admin account.
20. Keep Privacy and Compliance Current
Priority: Important | Owner: Owner
Rules attach to the data you hold, not the size of your company. Collecting cards brings PCI DSS into play, serving EU visitors brings GDPR, and handling patient information brings HIPAA. Keep your privacy policy and cookie consent accurate, and map the types of data you collect to the rules that apply. Healthcare products carry extra requirements, which we cover in our guide to custom healthcare software development.
If your site sits in a regulated sector, the evidence a partner can show matters as much as their promises. Our piece on website development agencies for regulated industries explains how to verify that evidence.
How to verify: Keep a short record of what personal data you collect, where it is stored and which rule covers it.
The Full Website Security Checklist Table
Copy this table into your project plan and mark each row as done, in progress or not applicable.
# | Check | Phase | Priority | Owner | How to verify |
|---|---|---|---|---|---|
What to Do If Your Website Is Hacked
Stay calm and work in order. Speed matters, but so does not destroying evidence.
- Contain it. Take the site offline or put it in maintenance mode, and disable compromised accounts.
- Preserve evidence. Save logs and take a copy of the affected files before you clean anything.
- Restore from a clean backup. Rebuild from a version you trust, then apply every pending update before going live again.
- Rotate every credential. Change passwords, API keys, database logins and tokens, not just the one you think was stolen.
- Notify and review. Tell affected users and regulators where the law requires it, then find the root cause and close it.
Common Website Security Mistakes
- Launching with default or shared credentials. Admin and database logins should be unique and stored in a password manager.
- Leaving the staging site public. Test environments often hold real data and weaker settings.
- Treating HTTPS as the finish line. Encryption protects data in transit, not a vulnerable application.
- Postponing updates. A patch delayed by a few weeks is often the whole story behind a breach.
- Never testing a restore. Many teams find out their backups are incomplete only when they need them.
Conclusion
A website security checklist earns its place by turning vague worry into specific jobs with owners and evidence. Get the ten launch checks right so you ship with a solid foundation, then run the ten ongoing checks on a calendar so the foundation does not erode. Agree who owns each one, keep the proof, and rehearse your incident plan before you need it.
If you are planning a new build or want a second opinion on an existing one, the team at SpaceToTech builds secure web applications with these checks built into delivery. You can talk to us about your project, and we will walk through what your site needs.
