Security guide · Romania

How do I protect a WordPress site from attacks?

Most hacked WordPress sites fall to outdated plugins, weak wp-admin passwords or pirated themes carrying a backdoor. All three are closed by a handful of settings and a maintenance routine, not by a random security plugin installed in a hurry.

Updated:

Short answer

  1. Protect a WordPress site by keeping core, themes and plugins updated and deleting everything you do not use.
  2. Turn on two-factor authentication for wp-admin and limit login attempts on wp-login.php and xmlrpc.php.
  3. Set permissions to 755 for directories and 644 for files, never 777, and never install nulled themes or plugins.
  4. Take a backup before every update and put a WAF at hosting level in front of the site.
Recommended permissions
directories 755, files 644, wp-config.php 600
Endpoints hit by brute force
wp-login.php and xmlrpc.php
Constant that blocks the dashboard file editor
DISALLOW_FILE_EDIT
Before any update
full backup, files and database

Where attackers get into a WordPress site

Automated scanners look for plugin versions with published vulnerabilities and exploit them within hours of the announcement, however small the site is. The second route is wp-login.php, where bots try lists of leaked passwords, while xmlrpc.php lets them test hundreds in a single request. The third is the pirated theme, which ships hidden code that opens a shell or injects spam links. Permissions set to 777 complete the picture: any other account on the same server can then write to your files.

What to do, in order of impact

Start with updates, because they close known vulnerabilities. Next comes access: long passwords, 2FA, login limiting and, unless you use the mobile app, xmlrpc.php switched off. Then harden the files: correct permissions, DISALLOW_FILE_EDIT in wp-config.php and no PHP execution inside wp-content/uploads. Finally put a hosting-level WAF in front, which filters malicious requests before PHP starts, and check that the daily backup really restores.

  • Delete deactivated plugins and themes instead of just switching them off
  • Use a username other than “admin” and a supported PHP version
  • Check for security updates every week

What Romanian law says

If the site has forms, customer accounts or a shop, you process personal data and fall under Article 32 GDPR, which asks for technical measures proportionate to the risk. ANSPDCP has fined missing measures in Romania, so an outdated WordPress that leaks customer data is more than a technical problem. A shop that issues invoices through e-Factura must also keep the XML files sent to ANAF, which turns backups into a legal requirement.

WordPress protection measures and what each one blocks
MeasureAttack it stopsWhere to configure it
Updates for core, themes and pluginsExploitation of published vulnerabilitiesWordPress dashboard or WP-CLI
2FA + login limitingBrute force on wp-login.phpAuthentication plugin
Disable xmlrpc.phpMass password guessing in a single request.htaccess or the web server
Permissions 755/644, DISALLOW_FILE_EDITWriting and editing files from the dashboardFile system, wp-config.php
Block PHP in uploadsExecution of uploaded files.htaccess or the web server
Hosting-level WAFSQL injection, XSS, botsHosting panel

Commands and configuration

Correct permissions for a WordPress install
find /var/www/example.ro -type d -exec chmod 755 {} \;
find /var/www/example.ro -type f -exec chmod 644 {} \;
chmod 600 /var/www/example.ro/wp-config.php
wp-config.php: no file editor in the dashboard
define('DISALLOW_FILE_EDIT', true);
define('FORCE_SSL_ADMIN', true);
.htaccess in wp-content/uploads: no PHP execution
<FilesMatch "\.php$">
  Require all denied
</FilesMatch>

Practical examples

WooCommerce shop in Cluj-Napoca

A slider plugin left unpatched for a year let an attacker upload a PHP file into uploads, and the shop began redirecting visitors to gambling pages. Restoring the daily backup, updating and blocking PHP execution in uploads fixed it the same day.

Law firm in Bucharest

The default admin user, with an eight-character password, was guessed through xmlrpc.php. The attacker created a hidden administrator and planted spam links in old posts. Two-factor login and disabling xmlrpc.php stopped it from happening again.

Common mistakes

  • Assuming an SSL certificate secures the site, when HTTPS only encrypts transport and does nothing about a vulnerable plugin.
  • Installing nulled themes and scanning them with a desktop antivirus, which cannot see obfuscated PHP.
  • Setting 777 on wp-content because “that is how uploads work”.
  • Updating without a backup and discovering you cannot roll back when a theme breaks.

How 4hosting helps

  • cPanel plans include a Let's Encrypt certificate and a daily backup, so recovery after an incident starts from yesterday's copy.
  • From the cPanel Advanced plan upwards you have 1 hour of CyberSecurity per month; you request it from the client panel, in the “DevOps Services” section, for example for a permissions audit.
  • WAF & DDoS Protection puts OWASP rules in front of the site and filters the bots that hammer wp-login.php.

Related questions

  • What do I do if my WordPress site has already been hacked?

    Take it offline for now, change every password, including the database and FTP ones, restore a backup from before the compromise and update everything before going live again. Check the administrator accounts and the cron entries in wp_options. Without a clean backup, look for recently modified files.

  • Do I need a security plugin?

    One good plugin for 2FA and login limiting is enough if the rest is in place: updates, permissions and a hosting-level WAF. Several overlapping security plugins slow the site down and add no real protection.

  • How often should I update?

    Apply security updates the day they appear, after a backup. Everything else can be batched weekly. Enable automatic minor core updates and check from time to time that the plugins you rely on are still maintained by their authors.

Request a security review

A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.