Lista de verificación de seguridad web: 20 cosas que comprobar ahora

Cyberattacks are no longer reserved for Fortune 500 companies and government agencies. In 2025, 43% of all recorded breaches targeted small and mid-sized businesses, according to Verizon's Data Breach Investigations Report. Attackers know that smaller organizations often lack dedicated security teams, making them low-hanging fruit for automated exploit kits that scan the internet around the clock. A single compromised contact form or outdated plugin can expose customer data, tank your search rankings, and trigger regulatory fines that dwarf the cost of prevention.

At GRADAX, we have seen the aftermath firsthand. A client running a regional e-commerce store came to us after their checkout page was injected with a credit card skimmer that operated undetected for eleven days. The financial damage was significant, but the reputational damage was worse — their repeat customer rate dropped by 38% in the quarter following disclosure. That incident crystallized a principle we now apply to every project: security is infrastructure, not an afterthought.

This checklist distills the twenty most impactful security measures we implement across our hosting and web development engagements. You do not need a six-figure security budget to execute them. Most can be completed in a single afternoon, and together they eliminate the vast majority of attack vectors that real-world threat actors exploit. Whether you manage your own servers or rely on a managed hosting provider, these checks apply to you.

Every page on your website should load over HTTPS with a valid SSL certificate. This is non-negotiable in 2026. Browsers flag HTTP sites as insecure, search engines penalize them in rankings, and any data transmitted without encryption, login credentials, form submissions, payment details, can be intercepted by anyone on the same network. Free certificates from Let's Encrypt have eliminated cost as an excuse, so there is no reason to delay.

Beyond installing the certificate, verify that your server enforces HTTPS by redirecting all HTTP requests with a 301 redirect. Check that your HSTS (HTTP Strict Transport Security) header is set with a max-age of at least one year and includes the includeSubDomains directive. This tells browsers to always connect via HTTPS, even if a user types the URL without the protocol prefix. We also recommend adding your domain to the HSTS preload list maintained by browser vendors, which bakes the HTTPS requirement directly into Chrome, Firefox, and Safari.

Common pitfalls include mixed content warnings, where a page loads over HTTPS but references images, scripts, or stylesheets over HTTP. Run a crawl with a tool like Screaming Frog or use your browser's developer console to identify mixed content issues. Every resource, fonts, analytics scripts, embedded iframes, API endpoints, must use HTTPS URLs. A single HTTP resource can cause the padlock to disappear and erode visitor trust.

Outdated software is the single most exploited attack vector on the web. WordPress core, plugins, themes, server operating systems, PHP runtimes, database engines, every layer of your stack receives security patches regularly, and every unpatched component is a documented vulnerability that attackers can exploit with off-the-shelf tools. The Equifax breach that exposed 147 million records was caused by a single unpatched Apache Struts dependency. Scale is not a prerequisite for catastrophe.

We recommend a disciplined update cadence: critical security patches within 24 hours of release, all other updates within seven days. For WordPress sites, enable automatic minor and security updates at minimum. For custom applications, integrate dependency scanning into your deployment pipeline, tools like Dependabot, Snyk, or Renovate will flag vulnerable packages before they reach production. If you are running on our managed hosting, we handle operating system and runtime patches automatically, but application-level dependencies remain your responsibility.

Test updates in a staging environment before applying them to production. We have seen well-intentioned security patches break payment gateways, contact forms, and authentication flows because a plugin update introduced an incompatibility. A five-minute staging test prevents a five-hour production outage. If your hosting provider does not offer a one-click staging environment, that alone is reason enough to consider switching to a provider that does.

Passwords remain the weakest link in most security chains. Credential stuffing attacks, where attackers test username-password combinations leaked from other breaches, account for over 60% of login-related attacks. If your WordPress admin password is "company2024" or your database root password is "password123", you are effectively leaving the front door unlocked. Every account with access to your website infrastructure should use a unique password of at least sixteen characters generated by a password manager.

Multi-factor authentication (MFA) is the single most effective defense against unauthorized access. Even if an attacker obtains a valid password through phishing or a data breach, they cannot log in without the second factor. We enforce MFA on every admin account across our hosting platform and strongly recommend our clients do the same for their CMS, domain registrar, DNS provider, email, and any SaaS tool with access to production data. Authenticator apps like Authy or hardware keys like YubiKey are far more secure than SMS-based codes, which are vulnerable to SIM-swapping attacks.

Limit the number of login attempts before triggering a lockout or CAPTCHA challenge. Five failed attempts within ten minutes should lock the account for fifteen minutes or require human verification. This simple measure stops brute-force attacks cold. Also audit your admin user list quarterly, remove accounts for former employees, contractors, and agencies you no longer work with. Every active account is an attack surface.

Backups are your last line of defense when everything else fails. Ransomware encrypts your files, a rogue plugin wipes your database, a developer accidentally deletes the production uploads folder — without a reliable, tested backup, any of these scenarios can mean permanent data loss. The question is not whether you need backups but whether your current backup strategy would actually save you in a crisis.

Follow the 3-2-1 rule: maintain at least three copies of your data, on two different storage media, with one copy stored offsite. For websites, this means automated daily backups stored on the same server (for fast restoration), replicated to a separate server or cloud storage bucket (for redundancy), and archived to a geographically distant location (for disaster recovery). Our backup and recovery infrastructure retains daily snapshots for thirty days, weekly snapshots for three months, and monthly snapshots for one year.

The most critical and most often neglected step is testing your backups. A backup you have never restored is a backup you cannot trust. Schedule a quarterly restore drill where you spin up a staging environment from your latest backup and verify that the site loads correctly, the database is intact, user uploads are present, and all functionality works. We have encountered clients whose backup jobs had been silently failing for months because disk space ran out or credentials expired. Discover that in a drill, not during an incident.

A web application firewall (WAF) sits between your website and the internet, filtering incoming traffic to block known attack patterns before they reach your application. It stops SQL injection attempts, cross-site scripting payloads, directory traversal attacks, and dozens of other exploit techniques that automated scanners probe for continuously. Without a WAF, your application code is the only line of defense, and a single overlooked input field can be the entry point for a breach.

Pair your WAF with regular malware scanning. Server-side scanners like ClamAV, Maldet, or commercial solutions from Sucuri or Wordfence inspect your file system for known malicious signatures, suspicious file modifications, and backdoor scripts that attackers plant for persistent access. Schedule scans daily and configure alerts for any detection. We also recommend file integrity monitoring that tracks checksums of critical files . WordPress core files, configuration files, server binaries, and alerts you immediately if any file changes unexpectedly.

At the network level, configure your server firewall to allow only the ports and protocols your application actually needs. A typical web server should expose port 443 (HTTPS), port 80 (HTTP, for redirect only), and your SSH port. Everything else, database ports, admin panels, development tools, should be blocked from public access and available only through a VPN or SSH tunnel. This simple hardening step eliminates entire categories of attacks that rely on exposed services.

The principle of least privilege is one of the oldest rules in information security, yet it is routinely violated. Every user, service account, and API key should have the minimum permissions necessary to perform its function, nothing more. A content editor does not need the ability to install plugins. A staging environment does not need production database credentials. A third-party analytics script does not need write access to your DOM.

Audit your WordPress user roles, hosting panel access, and server SSH keys at least quarterly. Remove or downgrade any account that has more privilege than it needs. For development teams, use role-based access control with named accounts, but never share a single admin credential among multiple people. Shared accounts make it impossible to trace who made a change, which is critical during incident investigation and required by most compliance frameworks including GDPR and PCI DSS.

API keys and service credentials deserve the same scrutiny. Rotate them at least annually, and immediately after any team member with access leaves the organization. Store them in environment variables or a secrets manager, never in source code or configuration files committed to version control. A single leaked API key in a public GitHub repository can be discovered and exploited within minutes, automated bots scan for them continuously.

Security monitoring transforms your defenses from passive barriers into an active detection system. Configure centralized logging that captures login attempts, file changes, permission modifications, error rates, and outbound network connections. Feed these logs into a monitoring platform that applies correlation rules and anomaly detection. A sudden spike in failed login attempts from a single IP range, an unexpected new PHP file in your uploads directory, or an unusual outbound connection to a foreign server, these are the early warning signs that precede a breach.

Equally important is having an incident response plan before you need one. Document the steps your team will follow when a breach is detected: who gets notified, how the affected system is isolated, where forensic evidence is preserved, how customers are informed, and when law enforcement or regulators should be contacted. Rehearse this plan at least twice a year. In our experience, organizations with a tested incident response plan resolve breaches 60% faster and incur significantly less financial and reputational damage than those who improvise under pressure.

If managing all of this sounds overwhelming, it should reinforce why working with a provider that bakes security into its infrastructure matters. At GRADAX, every hosting plan includes automated patching, daily malware scans, WAF protection, and 24/7 monitoring as standard features. Security is not an upsell, it is the baseline. If your current provider treats it as optional, reach out to us and we will show you what proactive security looks like in practice.