Here’s something interesting about LIKE in SQL - it is prone to injection and exploitation. It is unlike SQL injection, but still pretty dangerous. Hear me out…
A simple search feature can be (and probably is) implemented using a LIKE query. This is easy to exploit when the user-provided input contains wildcard characters.
When a wildcard percent sign (%) is given at the start of a user-provided query, and you take this and pass the string as-is to the SQL query under a LIKE clause, the database will treat it as valid input and execute it.
Because LIKE now starts with ’%’, the database performs a full table scan to find matching rows for the column.
So, if a normal email search completes in 0.01 seconds, but percent signs get inserted at the beginning, the same query can jump to 0.91 seconds. On larger tables, this gap widens significantly.
As you can see, this exploitation is pretty trivial to pull off. Someone could input patterns like %a%, and your query would scan through almost the entire table.
This isn’t full SQL injection where arbitrary commands get executed, but it’s still a denial-of-service. Attackers can slow down your database and exhaust connections.
The fix is straightforward: escape the LIKE metacharacters (%, _, and the backslash itself) before using user input in LIKE clauses. Most frameworks do not provide built-in helpers for this, so you will need to write your own escaping logic.
Just check your framework’s behavior with LIKE queries and inputs, and thank me later :)