Why securing your web server matters more than you think

Why web server security matters (even if you’re “small”)

A lot of smaller businesses and solo developers assume they’re too small to be a target. Unfortunately, that’s not how most attacks work. Many attackers don’t sit there picking companies by name – they run automated scans across the internet looking for websites with known weaknesses, then try to break in.

If your server is out of date, badly configured, or running code that doesn’t check input properly, the chances are high that someone will eventually find it. Not because they hate you personally, but because a script they’re running found a gap and tried its luck.

Common ways websites and apps get hacked

There are endless tricks and techniques out there, but most successful attacks fall into a few simple categories:

• Out-of-date software – old CMS installs, plugins, themes or frameworks with known bugs.
• Weak or reused passwords – especially for admin panels, hosting control panels and databases.
• Over-permissive file and directory access – places where code can run that never should.
• Badly handled input – forms and APIs that accept dangerous data without checking it.
• Misconfigured web server rules – for example, no protection on sensitive areas or uploads.

The good news? You don’t have to fix everything at once. Each area you tighten up reduces the overall risk.

What SQL injection actually is (without the buzzwords)

SQL injection is one of those terms that gets thrown around a lot, but it’s actually very simple when you strip away the jargon. It’s about tricking your website into sending a different question to the database than the one you intended.

Imagine you have a login form with an email and password field. Behind the scenes, your site might ask the database something like:

SELECT * FROM users 
WHERE email = 'alice@example.com' 
  AND password = 'secret123';

If your code simply drops whatever the user typed straight into that query without proper checks, an attacker can type in something deliberately weird instead of a normal email or password. For example:

' OR '1'='1

Now the query can turn into something like:

SELECT * FROM users 
WHERE email = '' OR '1'='1' 
  AND password = '';

Because '1'='1' is always true, the database might happily return a user row and your code may treat that as “logged in”. In more serious cases, the attacker can go beyond just logging in – they may be able to read, change or delete data as if they were the application itself.

The short version: SQL injection happens when user input is allowed to change the meaning of a database query. It’s prevented by:

• Always using parameterised queries / prepared statements.
• Never building SQL by gluing strings together from user input.
• Validating and sanitising what users are allowed to send.

Why .htaccess still matters (locking down where code can run)

On Apache-based servers, .htaccess is more than just a place for “friendly URLs”. It’s a control layer that decides what is and isn’t allowed in a given directory.

A classic example is the uploads directory. Your CMS or app might let users upload images or documents. That’s fine. What you don’t want is someone uploading a disguised PHP file and then running it in their browser.

With the right .htaccess rules, you can prevent PHP (or other scripts) from running in certain folders entirely. That way, even if a malicious file somehow lands there, it’s treated as harmless text, not executable code.

# In .htaccess inside /uploads (or via your main config)
<FilesMatch "\.(php|php5|phtml)$">
    Deny from all
</FilesMatch>

Practical steps you can take today

You don’t have to redesign your whole platform to make meaningful improvements. Here are straightforward actions you can take, even on a busy production site:

• Keep everything updated. CMS, plugins, themes, PHP version – old code is low-hanging fruit for attackers.
• Use strong, unique passwords. Especially for hosting, SSH, database and admin panels.
• Lock down uploads. Make sure user uploads can’t run as code. Use separate directories and .htaccess rules.
• Use HTTPS everywhere. In 2025, there’s no excuse for sending credentials over plain HTTP.
• Review directory listing. Disable automatic directory indexes so people can’t browse your file structure.
• Backups, backups, backups. A good, tested backup turns a worst-case scenario into an annoying afternoon, not a disaster.

Final thoughts

Security doesn’t have to be dramatic or mystical. In many cases, it’s a series of small, sensible decisions you make over time: where code can run, how input is handled, who can log in and what happens if something does go wrong.

You may never know how many attacks you’ve successfully avoided – and that’s exactly the point. A well secured web server is often the one you don’t have to think about, because it quietly refuses the wrong kind of attention.

For help reviewing or tightening up an existing setup, use the contact page to start a conversation.