WordPress Security Hardening -- Perth IT Care

Last month, a Perth accounting firm called us after discovering their WordPress site had been quietly compromised for weeks. Client data was at risk, their Google rankings had tanked, and they were staring down potential Privacy Act notification requirements. The worst part? Their previous developer had left the site wide open with default file permissions, unchanged database prefixes, and an exposed wp-config.php file that might as well have been a welcome mat for hackers.

Most Perth businesses think WordPress security means installing a plugin and keeping themes updated. That's like locking your front door but leaving all the windows open. The real vulnerabilities that hackers exploit aren't in your contact forms or image galleries -- they're in the server-level configuration that most developers never bother to harden properly.

The File Permission Problem Everyone Ignores

Your WordPress files have permission settings that control who can read, write, or execute them. Default installations often set these permissions far too broadly, giving hackers easy access once they find any small entry point.

The wp-config.php file is the crown jewel for attackers -- it contains your database credentials, security keys, and site configuration. If this file has standard 644 permissions, anyone who gains basic access to your server can read it. It should be set to 600 (readable only by the file owner) or moved entirely above your web root directory.

Your uploads folder is another common target. Many sites allow executable files to be uploaded and run from this directory, turning your image gallery into a potential backdoor. Directory permissions should be 755, and your .htaccess file should explicitly prevent script execution in uploads.

Most Perth web developers focus on getting sites working, not securing them properly. We regularly find business websites with 777 permissions (readable, writable, and executable by everyone) applied across entire directory structures. That's like giving every stranger on the street a key to your office.

Database Security Beyond Plugin Updates

WordPress security plugins can't protect what happens at the database level. Your MySQL database is where your real business data lives, and most installations leave it unnecessarily exposed.

Default WordPress installations use predictable table prefixes like "wp_". Changing these to something random makes automated attacks much harder. More importantly, many sites run everything through a single database user with full administrative privileges. Your WordPress application should only have the minimum database permissions it needs to function.

Database connections themselves are often unencrypted, sending login credentials in plain text between your web server and database server. If you're on shared hosting, this means other customers could potentially intercept your database traffic. WordPress hosting requirements become critical when you're dealing with sensitive business data.

Connection limits and timeout settings also matter for both security and performance. Unlimited database connections make it easier for attackers to overwhelm your site and extract data slowly over time.

Server Configuration That Actually Stops Attacks

The biggest WordPress security gaps happen at the server level, where most business owners never look. Your web server configuration determines what information gets revealed to potential attackers and how they can interact with your site.

WordPress version disclosure is enabled by default, broadcasting exactly which version you're running to anyone who checks. Attackers use this information to target known vulnerabilities. Your server should strip version numbers from meta tags, RSS feeds, and HTTP headers.

File editing through the WordPress admin panel is convenient for quick fixes but creates a massive security hole. The theme and plugin editors essentially give anyone with admin access the ability to execute any code they want on your server. These should be disabled entirely through wp-config.php settings.

Directory browsing is another common oversight. If someone navigates to a folder without an index file, many servers will display a full list of files and subdirectories. This gives attackers a roadmap of your site structure and potentially exposes backup files, configuration files, or other sensitive data.

XML-RPC functionality, used for things like mobile app publishing, has been a frequent attack vector. Unless you specifically need it, this should be disabled through server configuration rather than relying on plugins to block it.

User Access Hardening Beyond Strong Passwords

Default WordPress user configurations make brute force attacks much easier than they need to be. The standard "admin" username is the first thing attackers try, and many Perth businesses still use it despite years of security warnings.

User role restrictions often get overlooked in small business WordPress sites. Someone who needs to add blog posts shouldn't have the same permissions as the person managing the entire site. Yet we regularly find accounting firms where the receptionist's login has administrator privileges because "it's easier to manage."

Login attempt limiting needs to happen at the server level, not just through plugins. Server-based restrictions can block attackers before they even reach your WordPress installation, reducing server load and preventing sophisticated attacks that bypass plugin detection.

Two-factor authentication becomes meaningless if session management is poorly configured. Login sessions should expire appropriately, and concurrent session limits should be enforced to prevent account sharing or compromise.

Backup Verification and Recovery Testing

Having backups isn't the same as having working backups. Most Perth businesses discover their backup system was broken only when they need to restore from an attack or server failure.

Regular restoration testing should be part of your security routine. If you can't successfully restore your site from a backup within a reasonable timeframe, your backup system is effectively useless. This means having a staging environment where you can test restores without affecting your live site.

Database backups need to be consistent and complete. Many backup solutions only capture files, missing database changes that happened during the backup process. Your backup system should lock the database during capture or use transaction-safe methods to ensure data integrity.

Perth businesses often store backups in the same location as their website, which means a server compromise or hosting failure can destroy both your site and your recovery option. Proper backup security requires off-site storage with its own access controls and retention policies.