Website Security Best Practices and Checklist

Most business websites are not hacked because someone targeted them personally. They are hacked because an automated bot found an outdated plugin, a weak admin password or a forgotten test copy of the site, and used it. The attacker does not care whether you sell industrial equipment or handmade candles. Your site is simply one of millions being scanned every day.

The good news is that most of these attacks are preventable with basic, consistent work. This guide covers website security best practices for corporate sites and online stores: why security matters for the business, which threats are most common, a practical website security checklist, the extra requirements for stores that accept payments, how to protect WordPress and other CMS websites, how to test security and what to do if your site is hacked.

We build and maintain websites as part of our corporate website development and ecommerce work, so the checklist reflects what we apply on real projects. It is written for business owners and marketing managers, not only for developers, so we keep technical details at a level that helps you ask the right questions.

Why website security matters for business

In practical terms, website security is everything that keeps your site available, your data confidential and your content unchanged by people who should not touch it. Web security is the broader discipline that covers websites, web applications, APIs and the servers and services behind them. Specialists often describe the goals with three words: confidentiality, integrity and availability. Your data should be seen only by the right people, changed only by the right people, and accessible when customers need it.

When security fails, the consequences are concrete:

Downtime. A hacked or overloaded site stops working. For an online store, every hour offline is lost revenue. For a B2B company, it means lost leads and a damaged first impression for anyone who visits during that time.

Data breach. Customer names, emails, phone numbers, addresses and order history can leak. For stores, payment-related data is at risk too. A data breach brings direct costs (investigation, notification, legal advice) and indirect ones (lost trust, cancelled orders, bad press).

Fines. In the EU and for EU customers, GDPR fines can reach up to €20 million or 4 % of global annual turnover, whichever is higher, for the most serious violations. Most cases end with smaller penalties, but regulators do expect reasonable security measures and timely breach notification.

SEO damage. If Google detects malware or phishing on your site, Google Safe Browsing can show a red warning screen to visitors in Chrome and other browsers, and search results can display a “This site may be hacked” label. Traffic collapses within hours. Hacked sites are also used to inject spam pages and links that damage rankings long after the cleanup. HTTPS itself is a small ranking signal, and security is part of overall page experience. We explain how these factors fit with others in our article on Google website ranking factors.

Customer trust. Customers rarely return to a store that leaked their data or showed a malware warning. Trust takes years to build and one incident to lose.

Security is therefore not an IT topic. It is part of business continuity, just like insurance or accounting.

Most common website security threats

You do not need to understand how attacks work in detail to protect against them. But knowing the main categories helps you understand why each item on the checklist matters.

OWASP Top 10. The Open Worldwide Application Security Project publishes a list of the most critical web application security risks. The current 2025 edition is led by broken access control, security misconfiguration and software supply chain failures, followed by cryptographic failures, injection and insecure design. It is the standard reference for developers and auditors.

SQL injection. An attacker sends specially crafted input through a form or URL to make the database run unintended commands, for example to read or delete data. Modern frameworks prevent this by default when used correctly.

Cross-site scripting (XSS). Malicious scripts are injected into pages that other users view, for example through comments or form fields. They can steal sessions or redirect users.

CSRF. Cross-site request forgery tricks a logged-in user’s browser into performing an action they did not intend, such as changing an email address.

Brute-force attacks. Bots try thousands of password combinations on login pages, especially on well-known admin URLs.

DDoS. A distributed denial-of-service attack floods a site with traffic from many sources until it stops responding. Some attacks are political, some are extortion, some are competitors or simply random.

Malware. Malicious code injected into the site to steal data, redirect visitors, mine cryptocurrency or send spam.

Vulnerable plugins. On CMS websites, outdated or poorly written plugins and themes are the most common entry point for attackers.

Supply chain attacks. Attackers compromise a third-party library, package or service that your site depends on, and through it, your site. This is why the 2025 OWASP list moved software supply chain failures near the top.

Phishing and stolen credentials. Not every attack targets the code. Many start with an email that looks like it came from the hosting provider, the domain registrar or a colleague, asking someone to log in on a fake page. Once the attacker has a valid password, no firewall stops them. This is why two-factor authentication and staff awareness belong in a security checklist as much as technical settings.

Spam and form abuse. Contact forms, registration and comments attract bots that send spam, test stolen card numbers or overload email systems. It looks harmless, but it fills the CRM with junk, damages email reputation and sometimes hides more serious probing.

Website security checklist

This is the core of the guide. Before going through it, one practical note: most items here are not expensive or complicated individually. What makes security hard is consistency. A checklist works only when someone owns it, reviews it on a schedule and records what was done. Assign that owner, even if it is a contractor, and agree how often they report.

Each block contains the essentials. If you are wondering how to secure a website step by step, work through these blocks with your developer or hosting provider and mark what is done.

HTTPS and SSL/TLS

• Serve the entire site over HTTPS, not only checkout and login pages, and redirect all HTTP requests to HTTPS.

• Use modern protocols: TLS 1.3 where possible, TLS 1.2 as a minimum, and disable outdated versions.

• Enable HSTS (HTTP Strict Transport Security) so browsers always connect over HTTPS.

• Automate certificate renewal. Free certificates from Let’s Encrypt and most paid ones can renew automatically. This matters more every year: since March 2026, publicly trusted TLS certificates can be issued for a maximum of 200 days, and the limit will drop to 100 days in 2027 and 47 days in 2029. Manual renewal will soon be impractical.

• Check for mixed content, where an HTTPS page loads images or scripts over HTTP.

Updates and dependency management

• Update the CMS core, plugins and themes regularly, and apply security patches as soon as they are released.

• Keep server software current: supported PHP and Node.js versions, database and web server.

• Audit dependencies. Tools such as npm audit for JavaScript projects and Composer’s audit for PHP show known vulnerabilities in libraries. Dependabot and similar services can open update requests automatically.

• Remove unused plugins, themes and libraries. Every unused component is still an attack surface.

• Test updates on a staging copy before applying them to production.

Postponed updates are a classic form of technical debt: each skipped update makes the next one harder and riskier. We explain how this debt accumulates in our article on technical debt.

Access control and authentication

• Enable two-factor authentication (2FA) for every admin, hosting, domain registrar and CMS account.

• Apply least privilege: give each person only the access they need. Content editors do not need server access, and former contractors should lose access when their work ends.

• Set a password policy: long, unique passwords stored in a password manager, never shared in chats or documents.

• Protect the admin panel: change default login URLs where possible, limit login attempts, restrict access by IP for internal tools.

• Review accounts every quarter and remove those no longer needed.

Security headers

HTTP security headers tell browsers how to behave when loading your site. They are cheap to configure and block whole classes of attacks.

• Content Security Policy (CSP) defines which sources of scripts, styles and images the browser may load. It is the strongest protection against XSS.

• X-Frame-Options (or the frame-ancestors directive in CSP) prevents your pages from being embedded in other sites for clickjacking.

• X-Content-Type-Options: nosniff stops browsers from guessing file types in ways that can be exploited.

• Add a strict Referrer-Policy and a Permissions-Policy for browser features your site does not need.

Backups and recovery

• Follow the 3–2–1 backup rule: three copies of your data, on two different types of storage, with one copy off-site.

• Define RPO and RTO. Recovery point objective is how much data you can afford to lose (for example, the last hour of orders). Recovery time objective is how long the site may be down. These numbers decide how often to back up and how fast restore must work.

• Back up both files and database, automatically, and keep several versions, not only the latest.

• Store backups separately from the main server, so an attacker who gets into the server cannot delete them.

• Do restore testing regularly. A backup that has never been restored is a hope, not a backup.

Firewall, monitoring and logging

• Put a web application firewall (WAF) in front of the site. Services such as Cloudflare filter malicious requests, block known attack patterns and absorb many DDoS attacks before they reach your server.

• Use rate limiting on login pages, search, forms and APIs to stop brute-force attempts and abuse.

• Set up uptime monitoring with alerts by email or messenger, so you learn about problems before customers do.

• Keep access logs and application logs for a reasonable period, and make sure someone actually reviews alerts.

• Protect forms from bots with honeypot fields, rate limits and, where needed, a privacy-friendly challenge, so spam does not reach your CRM and inbox.

A WAF and good monitoring also give you data. After a few weeks you will see which pages bots target, which countries the attacks come from and whether a traffic spike was a marketing success or an attack. That data helps decide where to invest next.

Hosting and server hardening

Web hosting security is the foundation everything else stands on.

• Prefer managed hosting or a professionally maintained server for business sites. Cheap shared hosting with outdated software puts you next to neighbors you do not control.

• Keep server updates applied, including the operating system.

• Set correct file permissions so web processes cannot modify code or configuration files.

• Use isolated environments: separate production, staging and development, and never leave test copies of the site publicly accessible.

• Disable services and ports you do not use.

Third-party scripts and contractors. A modern business site loads code from many places: analytics, tag managers, chat widgets, booking tools, ad pixels. Each of these scripts runs with the same rights as your own code, so a compromised or careless vendor can affect your visitors. Keep a list of every external script, remove the ones nobody uses, and load critical libraries with Subresource Integrity where possible, so the browser refuses a file that has been changed.

The same logic applies to people. Agencies, freelancers and former employees often keep access long after a project ends. Make access part of every contract: who gets which accounts, how they are protected and when they are removed. Ask contractors to work through personal accounts with two-factor authentication rather than a shared admin login.

Where to start if the list feels long. Not everything has to be done in one week. A practical order for most business sites looks like this:

• First week: turn on two-factor authentication for every admin, hosting and domain account, remove old users, check that HTTPS works everywhere and that automatic backups exist and are stored off the main server.

• First month: update the CMS, plugins and server software, put a WAF in front of the site, set up uptime monitoring and add the basic security headers.

• First quarter: run a vulnerability scan, test a full restore from backup, review hosting configuration and write a one-page incident plan.

This order closes the most common entry points first: stolen passwords, outdated software and the lack of a way back after an incident. The more advanced items, such as a strict Content Security Policy or a penetration test, come after the basics are stable.

Extra security requirements for online stores

When a site accepts payments and stores customer data, the stakes rise and so do the requirements. Ecommerce website security adds several layers.

PCI DSS. Any business that accepts card payments must comply with the Payment Card Industry Data Security Standard. Version 4.0.1 is the current version, and all of its requirements have been mandatory since March 31, 2025. The simplest way to reduce scope is to never let card numbers touch your servers.

Hosted payment fields and tokenization. Use the payment form or hosted checkout of your payment provider. The provider stores card data and gives your store a token instead. Your systems never see the full card number.

3-D Secure. Additional cardholder authentication, usually a confirmation in the banking app, reduces fraud and shifts liability for many fraudulent transactions away from the merchant.

Fraud detection. Payment providers and dedicated services score transactions for fraud risk based on location, device, behavior and order patterns. Configure rules for high-risk orders, such as manual review for unusual amounts.

Data encryption. Encrypt sensitive data in the database and in backups, not only in transit.

Privacy laws. GDPR in the EU, CCPA in California and similar laws require a lawful basis for processing, data minimization, clear privacy notices and prompt breach notification. Collect only what you need for orders and marketing you have consent for.

If you are planning a new store or rebuilding an existing one, these requirements should be part of the architecture from day one. Our ecommerce development services include payment security and privacy compliance as standard.

Security for WordPress and other CMS websites

WordPress powers a large share of the web, which also makes it the most targeted CMS. The core itself is maintained and patched regularly. Most WordPress hacks come from plugins, themes, weak passwords and outdated installations. A short WordPress security checklist:

• Plugin vetting. Install plugins only from reputable developers with recent updates and many active installations. Fewer plugins means fewer risks.

• Automatic updates for minor core releases and security patches, with regular updates of plugins and themes after testing.

• Security plugin. Tools such as Wordfence add a firewall, malware scanning and login protection at the application level.

• XML-RPC. Disable it if you do not use it. It is a frequent target for brute-force and amplification attacks.

• File editing. Turn off the built-in file editor in the admin panel.

• Admin accounts. 2FA, no default “admin” username, limited number of administrators.

The same principles apply to other CMS platforms. For projects where security and performance are critical, a headless CMS can reduce the attack surface: the content management system is not publicly exposed, and the website is served as a separate frontend. If you work with WordPress or plan to, our WordPress development team can audit and harden an existing installation or build a secure one from scratch.

Nulled themes and plugins. Pirated premium themes and plugins, often shared for free on forums, are one of the most common sources of hidden malware on WordPress sites. They look identical to the original, but frequently contain backdoors that give attackers access weeks or months later. Saving on a license here often costs much more in cleanup. Buy from the original developer or use well-maintained free alternatives from the official repository.

Security testing and audits

Security is not a one-time setup. It needs regular checks.

Vulnerability scanning. Automated scanners check your site for known vulnerabilities, outdated software and misconfigurations. Run them at least monthly and after major changes. OWASP ZAP is a free, widely used scanner. Burp Suite is the standard professional tool for deeper testing.

Web app security testing. For custom web applications, portals and stores, automated scans are not enough. Testing should cover authentication, access control between users and roles, input validation and business logic, for example whether one customer can see another customer’s orders by changing an ID in the URL.

Penetration testing. A penetration test is a controlled attack by specialists who try to break in the way a real attacker would. It is worth doing before launching a store or portal with sensitive data, after major changes and at least once a year for critical systems.

Security audit. A broader review of code, configuration, hosting, access rights and processes. A web application security checklist, such as the OWASP Application Security Verification Standard, helps structure it.

How often should you check? A practical rhythm for most business sites: automated monitoring continuously, vulnerability scans monthly, an access review quarterly and an external audit or penetration test yearly. Most of these tasks belong to regular site maintenance, which we cover in our guide to website maintenance.

What to do if your website is hacked

If you suspect a hack, act calmly and in order. An incident response plan prepared in advance saves hours when they matter most.

1. Confirm and contain. Check the signs: warnings in browsers, strange redirects, unknown admin users, new files, spam pages in search results. Put the site into maintenance mode or take it offline if it is spreading malware or leaking data. Isolation limits the damage.

2. Preserve evidence. Before cleaning, save logs and a copy of the infected files. They help understand how the attacker got in.

3. Change all credentials. Hosting, CMS admins, database, FTP or SSH, domain registrar, payment provider, connected services. Enable 2FA wherever it was missing.

4. Find the entry point. Outdated plugin, weak password, leaked credentials, vulnerable custom code. Without fixing the cause, the site will be hacked again within days.

5. Clean or restore. Restore from a backup made before the infection, then apply all updates. If no clean backup exists, specialists remove malicious code manually.

6. Request a review. In Google Search Console, check the Security Issues report and, after cleaning, request a review so warnings are removed from search results and browsers.

7. Notify users if data was affected. Privacy laws may require notifying regulators and affected customers within strict deadlines. In the EU under GDPR, the deadline for notifying the regulator is 72 hours after becoming aware of a breach.

8. Learn and improve. Update the checklist, monitoring and processes so the same thing does not happen again.

Prepare before anything happens. The worst moment to look for passwords and phone numbers is during an incident. Keep a short document, stored outside the website and hosting, with: who owns the site and makes decisions, contacts of the hosting provider, developer and domain registrar, where backups are stored and how to restore them, and a template message for customers. Review it twice a year. Teams that have this page restore a site noticeably faster, because nobody wastes time finding out who can do what.