Database Security and How to Secure Your Web Servers (2026 Guide)

Web servers and the databases behind them hold what attackers want: customer records, credentials, orders, payment references. That is why database security and web server hardening still decide how bad a breach gets. An attacker who lands on a well-configured server with an isolated, encrypted, least-privilege database finds very little. One who lands on a default installation with an admin password in a config file finds everything.

We first published this guide in 2017. The principles have aged well, but the tools, the threats and the hosting have changed: most databases now run on managed cloud services, secrets live in vaults rather than config files, and attackers exploit unpatched software faster than ever. This 2026 version covers what to do on each front, with references to the guidance from the UK’s NCSC and OWASP.

Contents

1. Why database security matters more in 2026
2. Shrink the attack surface
3. Encrypt data in transit and at rest
4. Keep secrets out of code and config files
5. Least privilege for services, applications and people
6. Patch on a schedule you can prove
7. Backups you have actually restored
8. Managed databases and cloud hosting
9. A web application firewall in front of the server
10. Logs that someone actually reads
11. Test it before someone else does
12. How Yeeply can help

Why database security matters more in 2026

The way attackers get in has shifted. Verizon’s 2026 Data Breach Investigations Report found that 31% of breaches now start with the exploitation of software vulnerabilities, ahead of stolen passwords, and that 48% of breaches involve ransomware. Both point straight at servers: unpatched software is the way in, and the database is what gets encrypted or copied.

UK businesses are not keeping pace. According to the government’s Cyber Security Breaches Survey 2025/2026, 43% of businesses identified a breach or attack in the previous 12 months, yet only 34% have a policy to apply security updates within 14 days.

Whatever operating system, web server or database engine you use, an out-of-the-box configuration is rarely secure enough for production. The tasks below are the ones that make the biggest difference. The NCSC’s 10 Steps to Cyber Security is a good companion if you need the wider organisational picture.

Shrink the attack surface

Default installations come with network services, modules and extensions a web server doesn’t need. Each one is another open port or another piece of code an attacker can target. Turn off and disable everything you don’t use, so it doesn’t come back after a reboot: remote access services, print services, sample applications, unused Apache or Nginx modules, unused IIS handlers and extensions. As a bonus, the server frees up resources.

The database itself should never be reachable from the internet. Put it on a private network or subnet, allow connections only from the application servers that need it, and close the default ports to everyone else. Exposed database ports are still one of the most common findings in external tests.

Separate development, testing and production. It is still tempting to build and test directly on the production server because it is quicker. It is also how forgotten /test/ or /new/ directories, debug pages and internal admin tools end up public. Development and test environments should be separate from production, should not hold real customer data (use masked or synthetic data instead) and should not be able to connect to production databases.

Keep website files, logs and system files on separate drives or volumes too. If an attacker gets into the web root, that separation makes it harder to escalate to the rest of the disk and the operating system.

Encrypt data in transit and at rest

Every connection should be encrypted: browser to web server, web server to API, application to database. The NCSC’s guidance on using TLS to protect data recommends TLS 1.3, accepts TLS 1.2 with the right configuration, and says TLS 1.0, 1.1 and every version of SSL must be disabled. Internal connections count: traffic between an app server and a database inside the same network is not automatically safe.

For data at rest, the basis of database security is the encryption your database engine or cloud provider offers for storage, snapshots and backups. Add field-level encryption for the most sensitive columns, such as identity numbers or health data. Passwords are a separate case: they should never be encrypted or stored in plain text, only hashed with an algorithm designed for passwords, as the OWASP Password Storage Cheat Sheet explains.

Encryption is only as good as its key management. Keep keys in a key management service or hardware module, separate from the data they protect, and limit who can use them.

Keep secrets out of code and config files

Database passwords, API keys and certificates still turn up in configuration files inside the web root, in environment files committed to Git and in old backups. Once an attacker reads one of those files, every other database security control is irrelevant.

The OWASP Secrets Management Cheat Sheet sets out the approach: store secrets in a dedicated secrets manager or vault, give each application its own credentials, rotate them on a schedule and immediately after any suspected leak, and scan your repositories for secrets before code is merged. Where your platform supports it, short-lived credentials issued on demand are better than long-lived passwords.

Least privilege for services, applications and people

If an attacker compromises a network service, they inherit the permissions of the account it runs under. Run each service with the minimum privileges it needs, and never as root or a local administrator.

The same goes for the application’s connection to the database. A web application that only reads and writes customer orders doesn’t need permission to drop tables or read the users table of another system. Create separate database accounts for each application and each purpose (reading, writing, migrations), and give anonymous website visitors access only to what the site needs to show them. The OWASP Database Security Cheat Sheet covers the configuration details for the common engines.

For people:

• Disable or remove default and unused accounts created by the operating system, the database or installed software, and review the permissions of the ones you keep.
• Don’t use built-in administrator or root accounts for daily work. Each administrator should have a named account with the privileges their role requires, and accounts should never be shared.
• Require multi-factor authentication for every administrative access, including the hosting control panel and the cloud console.
• Administer servers from dedicated, well-protected devices and remove access promptly when someone changes role or leaves. The NCSC’s guidance on secure system administration explains how to set this up.

Patch on a schedule you can prove

A fully patched server is not automatically secure, but an unpatched one is an easy target, and the DBIR figures above show attackers know it. Patching covers more than the operating system: the web server, the database engine, the language runtime, the CMS and its plugins, and the libraries your application depends on.

A useful benchmark in the UK is Cyber Essentials, which expects critical and high-risk security updates to be applied within 14 days of release. To meet it, you need an up-to-date inventory of what runs on each server, automatic updates where they are safe, and a short test-and-deploy routine for the rest. The NCSC’s vulnerability management guidance explains how to prioritise when everything seems urgent. Software that no longer receives security updates should be replaced or isolated.

Backups you have actually restored

With ransomware involved in almost half of breaches, backups belong in your security plan. 74% of UK businesses back up data through a cloud service, according to the same government survey, but a backup that the attacker can reach with the same credentials can be encrypted or deleted along with everything else.

The NCSC’s advice on offline backups in an online world boils down to this: keep at least one copy that is offline or immutable, protect backup accounts separately from production accounts, encrypt backups, and restore from them regularly to prove they work. Agree in advance how much data you can afford to lose and how long you can be down, and check that your backup schedule matches.

Managed databases and cloud hosting

Managed database services, from Amazon RDS to Azure SQL and Google Cloud SQL, take care of engine patching, replication and much of the backup work. They don’t take care of your configuration. The NCSC’s shared responsibility model is clear on this: the provider secures the platform, and you remain responsible for access, data and settings.

In practice, the usual cloud mistakes are a database instance with public access switched on, network rules that allow connections from anywhere, snapshots shared publicly, and identity permissions granted far more widely than needed. Review these settings when you deploy and after every significant change, and use the provider’s own configuration checks. When choosing a provider, the NCSC’s cloud security principles are a solid list of questions to ask.

A web application firewall in front of the server

A web application firewall (WAF) filters requests before they reach the web server and blocks common attacks such as SQL injection, cross-site scripting and automated scanning. Most CDN and cloud providers offer one, and open-source rule sets such as the OWASP CRS are a reasonable starting point if you run your own.

A WAF buys time; it doesn’t fix vulnerable code. Injection, broken access control and security misconfiguration all remain in the OWASP Top 10:2025, and the fix for each is in the application: parameterised queries, authorisation checks on every request, and secure defaults. Use the WAF to cut noise and protect you while those fixes ship.

Logs that someone actually reads

For database security, logs are the record of every attempted and successful intrusion, and they are still ignored more often than not. Collect operating system, web server, application and database logs in a central place, separate from the servers that produce them, so an attacker who compromises a server can’t erase their tracks.

Log authentication events, privilege changes, failed queries, access to sensitive tables and configuration changes, without writing passwords or personal data into the logs themselves. The NCSC’s introduction to logging for security purposes and the OWASP Logging Cheat Sheet cover what to record and for how long. Then set alerts for the patterns that matter, such as repeated failed logins to the database or large exports at unusual times, and make sure someone is responsible for responding to them.

Test it before someone else does

Configuration drifts. A setting changed during an incident, a new plugin or a rushed deployment can undo months of hardening. Combine automated vulnerability scanning with a periodic external review: a configuration audit of servers and databases, and a penetration test of the web application and its infrastructure at least once a year and after major changes. Our guide to penetration test costs in the UK explains what each type of test covers and how to scope it.

How Yeeply can help

At Yeeply we work with certified companies specialising in cybersecurity services for companies: server and database hardening, cloud configuration reviews, penetration testing and monitoring. We select and supervise them, put comparable proposals in front of you with clear scope, timeline and price, and follow the project until it is delivered.

If the problem is the application itself, the certified companies behind our custom software development service can rebuild or modernise it with database security designed in from the start. If you’re planning a new web project, our guide to the advantages and disadvantages of web apps is a good place to begin.

If you’d like a proposal, click “Receive price estimate” at the top right of yeeply.com/en or email us at sales@yeeply.com. Tell us where your servers and databases are hosted and what you need reviewed.