Every form on your website, search box, contact form, login field, sends data somewhere. If that data lands straight inside a database command without being checked first, an attacker can write part of that command themselves. That is SQL injection, and it is one of the oldest tricks in web security that still works today.

What SQL injection actually is

OWASP’s Top 10 puts it plainly: injection happens when untrusted data is interpreted as part of a command, query, expression, or document structure instead of being treated as plain text. In a vulnerable contact form, typing a crafted string into a name field can turn into a database instruction instead of a name, letting an attacker read, change, or delete data that was never meant to be reachable from the front end.

It is still a live threat, not ancient history

SQL injection is tracked across more than 14,000 known CVEs, more than almost any other single vulnerability class. Injection flaws as a category carry the highest CVE count of any risk in OWASP’s current Top 10, spanning 37 separate weakness types, and OWASP notes that essentially every application it tested was checked for some form of it, a sign of how common the underlying mistake still is.

Why modern frameworks help but do not fully solve it

Tools like parameterized queries and modern ORMs handle the escaping automatically, which is why injection has slipped down the rankings compared to a decade ago. The risk concentrates instead in older code, custom-built forms, and plugins that build queries by joining strings together by hand, exactly the kind of code a small business site picks up over the years from different developers and plugin authors.

A basic check

  • Ask your developer or agency directly whether every form on the site uses parameterized queries or prepared statements, not string concatenation.
  • Keep any plugin that touches the database (forms, search, custom fields) updated, since injection fixes are a common reason for a point release.
  • Never build custom SQL by hand in a quick-fix snippet without escaping user input through your platform’s standard method.

AuditMerlin will not run exploit attempts against your forms, its scan is strictly non-invasive, but it does flag the exposed files and WordPress fingerprinting issues that often travel alongside unpatched, vulnerable code. A free scan is a reasonable starting point before asking a developer to check your forms directly.