The HTTPS padlock does not make your website secure

A small padlock icon sits in the address bar of a web browser. For many, this symbol is a green light. It suggests that the connection is secure and the site is safe to use. This feeling of safety is not entirely unfounded.

In the early days of the web, stealing data was easy if someone sat between the user and the server. This is called a Man-in-the-Middle attack. HTTPS was created to stop this. It encrypts data in transit. Encrypting means scrambling the information so only the sender and receiver can read it. Because HTTPS stops these eavesdroppers, it became a shorthand for general security. It seemed logical that if the pipe was secure, the destination must be too.

The armoured van#

Think of HTTPS as an armoured van transporting cash across a city. The van prevents thieves from stealing the money while it is on the road. It does its job perfectly. However, once the van arrives at the bank, the driver opens the door and hands over the contents. If those contents include a bomb instead of cash, the armouring of the van provides no protection. The van ensured the bomb arrived safely and without interference.

This is how SQL injection works. SQL is a language used to talk to databases. An injection attack happens when a malicious user sends a command disguised as normal data. For example, instead of a username, a person might send a piece of database code. If the application does not check this input, it passes the code directly to the database. The database then executes the command, perhaps revealing every password in the system or deleting entire tables of data.

Inside the application#

HTTPS protects the journey, not the destination. Transport Layer Security, which is the technology behind HTTPS, ensures that no one can read or change the data while it travels. But once the server receives the request, it decrypts the data to see what is inside. The malicious payload arrives perfectly intact and perfectly encrypted. The encryption has worked exactly as intended. It has safely delivered a weapon directly into the heart of the application.

When a developer relies on HTTPS to stop injection, they are confusing transport security with application security. One manages the road; the other manages the building. A site can have a valid certificate and an encrypted connection while remaining completely vulnerable to a basic attack. The encryption does not scrub the data or check it for malice. It simply ensures that the malicious request is not intercepted by a third party during its flight across the internet.

Relying on HTTPS to stop injection is like locking the front door but leaving the safe open in the middle of the room. Security requires a defence in depth. This means having multiple layers of protection so that if one fails, others remain. To stop SQL injection, developers must use prepared statements. These are templates that tell the database exactly what to expect, so it cannot be tricked by unexpected code. Input validation is also key. The application should recognise and reject any data that does not fit the expected format before it ever reaches the database layer.

Search the codebase for instances where user input is added directly into SQL queries through string concatenation. Replace these with parameterised queries using a trusted library. Ensure all user-facing forms have strict validation rules to filter out suspicious characters. Do not rely on the presence of a padlock icon to guarantee the safety of the database.