Requirements:
1. Familiarize yourself with the recommendations for developers (Appendix 1) regarding the security
of the site and inform whether these recommendations can indeed provide a high
level of protection for the WordPress site.
2. Check the implementation of these recommendations on the current site.
3. If the recommendations described in Appendix 1 do not provide an adequate level
of protection, provide other recommendations, according to working with WordPress.
4. If the recommendations described in Appendix 1 meet the appropriate level
of protection, recommend to the client's team (in simple language) how we
can further improve the security situation. What to do? How often to check?
Provide advice regarding updates, etc.
Appendix 1. Security recommendations from the previous developer
"This is about Cybersecurity our capabilities:
Website protection complex:
1. Network level - Traffic filtering and DDoS protection
Cloudflare
● Hides the IP address of the main server - all requests go through Cloudflare,
attackers do not see the real IP
● Protects against DDoS - includes automatic captcha, slowing down suspicious IPs
-Filters traffic - blocks SQL injections, XSS, brute force, and suspicious user-agents
Traffic filtering on the server (Nginx/Apache)
● Limits the number of requests to /wp-login.php and /xmlrpc.php (Rate Limiting)
● Limits the number of connections from a single IP
● Blocks known bots and parsers
2. Access to the WordPress admin (/wp-admin)
IP-based login restrictions
● Access to the admin is allowed only from whitelisted IPs
Changing the admin URL
● Change the standard /wp-admin to a custom path (/mysecretadmin)
● Accessible only after entering a secret token
Two-factor authentication (2FA)
● Add a confirmation code via Telegram or Google Authenticator
● Even if the login/password are leaked, the attacker cannot log in
Can be implemented with custom code or use Wordfence 2FA.
3 Database - SQL injections and backups
Disabling remote access to MySQL
● MySQL listens only to local connections
Using secure SQL queries
Automatic backup creation
● Daily database backups
● Copying backups to a remote server or cloud
4. File system protection
Disabling PHP execution in uploads/ and wp-content/
● So that an attacker cannot upload and run a malicious PHP script
Disabling code editing from the admin
● Prohibiting changes to themes and plugins via /wp-admin
Monitoring file changes
● Running a script that checks if critical files have been changed
5. Failover (automatic switch to backup server)
● The site automatically switches to a backup server if the main one fails
● The database is replicated in real-time
● Everything happens transparently for users (without changing the domain)
How it works:
1-Main server (A) dies
2-Cloudflare DNS Failover automatically switches to server B
3-MySQL Replica switches to the new master
Implementation:
Cloudflare Load Balancer
MySQL Replication (Master-Slave)
rsync for file synchronization
6. Implementation of the "hybrid static site" logic
Main server (admin and content generation)
Runs on WordPress
Administrators manage content through /wp-admin
After updating the content, a script is triggered to generate static HTML pages
Frontend server (only HTML, CSS, JS)
Receives ready static pages from the main server
Located on another server (or CDN)
Does not contain WordPress, PHP, and databases
Works like a regular static site
Dynamic elements (feedback, search, cart, etc.)
● Implemented via REST API or GraphQL
● All forms and requests go to the API on the main server
Additional improvements
● API caching - via Cloudflare Workers or Nginx FastCGI Cache
● Static synchronization on schedule - once an hour/daily
● Moving search to a separate service
● Protecting the API with tokens - so that spammers do not send tons of requests