The Risks That Sink Websites (and How to Avoid Them): Security

After exploring how data loss can take down any website, it’s time to look at the second major threat they all face: the security vulnerabilities that leave your site exposed to attacks.

Your hosting provider works hard to secure the server you’re on – firewalls, patches, isolation layers – all of that helps.

But that doesn’t automatically make your website safe.

The truth is, most successful attacks don’t come from breaking into servers – they come from exploiting websites.

Think of it as a numbers game: attackers rarely target your site specifically. 

Instead, they run automated scans across thousands of sites, hunting for easy wins – outdated plugins, default admin pages, known exploits.

If your site looks secure, they move on. If it doesn’t, you’re on the list.

The good news? Securing your site isn’t nearly as complicated as it sounds. Many of the most important steps are things you do once and rarely think about again – but they make a world of difference in keeping bad actors out.

Here’s how to keep your website “doors” closed whenever someone with bad intentions comes knocking.

1. Don’t Use “Nulled” or Untrusted Software

This is one of the most common and avoidable mistakes.

Using cracked, nulled, or otherwise unverified software is asking for trouble.

These versions often contain backdoors, malware, or spam relays hidden deep inside. 

You won’t notice them until it’s too late – when your site is blacklisted, or your server starts sending spam emails.

Avoid this entirely by:

• Installing software only from official or verified sources;
• Checking checksums or digital signatures when available;
• Looking for free or open-source alternatives if the paid version is out of budget;
• Or, if no alternatives exist, consider building your own or partnering with a developer. It might even become a new market opportunity.

2. Enable a Web Application Firewall (WAF)

A Web Application Firewall (WAF) sits between the internet and your website. 

It automatically blocks the most common attacks – SQL injections, cross-site scripting (XSS), and other malicious requests – before they ever reach your code.

Most hosting providers have WAF protection enabled by default. But if you need to set it up manually, here’s how to do it using Apache + ModSecurity:

Enable ModSecurity

# Enable modules (Debian/Ubuntu)
a2enmod security2 headers
# httpd.conf or conf-enabled/security.conf
SecRuleEngine On  # Off to disable quickly
# Load OWASP CRS (adjust path to your installation)
Include /etc/modsecurity/crs/crs-setup.conf
Include /usr/share/modsecurity-crs/rules/*.conf

This loads the OWASP Core Rule Set (CRS) – a collection of well-maintained, community-verified security rules that protect against 99% of common attacks.

They update regularly, so you’re always covered against new threats.

Advanced Users: Custom Rules

ModSecurity lets you go further by creating custom rules tailored to your site.

But be careful – poorly written rules can break functionality or block real users.

Always test new rules in a staging environment before applying them to your live site.

3. Hide or Harden Admin Paths and Legacy Endpoints

One of the easiest ways attackers gain access to a website is by going straight for the login page. 

Bots constantly scan the internet looking for common URLs like /admin or /login. 

When they find these pages, they save them for later and often launch automated attacks using stolen or commonly used passwords.

If your login page is easy to find, you’re already on a hacker’s radar – even if they don’t know anything about your site.

Of course, using strong, unique passwords and throwaway email addresses is essential.

But there are also simple ways to make your login area much harder for attackers to discover or access.

Here’s how to close that “door”:

Option A: Restrict Access to Your Login URL (IP Whitelisting)

This can be done in your .htaccess file:

<LocationMatch "^/(admin|wp-admin|user/login)$">
  Require ip 203.0.113.0/24
  Require ip 2001:db8::/32
</LocationMatch>

Pros:

• Extremely effective – your login page becomes invisible to the world.

Cons:

• New IP addresses must be added manually.
• Not ideal if multiple users need access from different locations.

But if the login page is for your eyes only, this is one of the best protections you can add.

Option B: Change Your Login URL

Another simple but powerful trick is changing the URL of your login page.

Bots look for predictable paths like /admin or /login. They won’t find something custom like /ninja or /manager.

You don’t need anything complicated – just avoid obvious words like admin, user, or login.

Instead of: my-site.com/admin.php

use: my-site.com/ninja or my-site.com/manager

Example .htaccess rule:

# START Custom Login URL
RewriteEngine On
RewriteBase /

# 1. Block direct access to the default login page (Optional but Recommended)
# This prevents people from knowing the default path still works.
RewriteRule ^admin\.php$ - [R=404,L]

# 2. Allow access to the new custom URL /ninja
RewriteRule ^ninja$ wp-login.php [L]

# END Custom Login URL

Most CMS platforms also offer plugins that handle this for you automatically.

Option C: Disable Unused Legacy Endpoints (e.g., XML-RPC)

XML-RPC is a protocol that allows applications to interact remotely with your website – for example, publishing posts from a desktop editor. 

But the same functionality is widely exploited for malicious purposes such as:

• DDoS attacks
• brute-force logins
• password guessing

If you aren’t using XML-RPC, disable it:

Here is how you can do it with .htaccess:

<Files "xmlrpc.php">
  Require all denied
</Files>

Removing unused entry points makes your site significantly harder to attack.

Option D: Transport & Browser Security Defaults

Today’s web browsers come with powerful built-in security features – but your site must explicitly tell them to activate these protections.

At minimum, you should be using:

• SSL/TLS: Encrypts all traffic between your site and visitors;
• HSTS: Ensures browsers always use HTTPS;
• Security headers: Help prevent browser-side attacks like XSS or clickjacking.

Here’s how to add these security headers in Apache:

Apache security headers + HSTS

# Security Headers
<IfModule mod_headers.c>
   Header set X-XSS-Protection "1; mode=block"
   Header set X-Frame-Options "SAMEORIGIN"
   Header set X-Content-Type-Options "nosniff"
   Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
   Header set Referrer-Policy "same-origin"
   Header set Feature-Policy "geolocation 'self'; vibrate 'none'"
  # Report-Only so you can observe, then enforce later
  Header always set Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'"
</IfModule>

Be careful when working with the Content-Security-Policy (CSP) header. It’s a powerful security feature, but even small mistakes can break parts of your website – such as images, styles, or scripts not loading correctly. 

Before enforcing any CSP rule, take time to test how your site behaves and make changes gradually.

Here’s a simple, beginner-friendly CSP rule you can start with:

Header set Content-Security-Policy "default-src https:; font-src https: data:; img-src https: data:; script-src https:; style-src https:;"

This setup lets your site load images and fonts from trusted sources, even if they aren’t served over HTTPS, but requires everything else (scripts, styles, core resources) to be delivered securely. 

4. PHP Security Basics

PHP settings also play an important role in securing your website.

Here are some simple improvements you can apply in your php.ini file:

; php.ini
session.cookie_secure=1
session.cookie_httponly=1
session.cookie_samesite=Lax
; Production performance
opcache.enable=1|
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
zend.assertions=-1

NOTE: Always keep a backup of your original .ini file so you can revert changes if something goes wrong.

***

Security is not about making your website unbreakable.

It’s about making it not worth attacking.

Most attacks are automated, opportunistic, and based on scanning thousands of sites for easy entry points. By:

• using trusted software
• enabling ModSecurity
• hiding or restricting admin paths
• disabling outdated endpoints
• enforcing modern browser protections
• strengthening PHP security

… you close nearly all the most common doors attackers rely on.

In the next part of this series, we’ll cover the third major risk – performance, and explore how slow loading, poor caching, and inefficient hosting setups can cost you traffic, sales, and search rankings.

Stay tuned for:
The Risks That Sink Websites (and How to Avoid Them): Performance

Originally published Tuesday, January 6th, 2026 at 2:11 pm, updated January 6, 2026 and is filed under Online Security.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.