Mosfetti Forum

SQL injection is old enough to have a museum wing — and new enough to still appear in bug bounty reports every week. The core mistake has not changed: untrusted input is allowed to change the meaning of a query.

Computerphile’s classic demonstration remains one of the clearest visual explanations:
https://www.youtube.com/watch?v=ciNHn38EyRc

The idea in one paragraph

If a web app builds SQL by gluing strings together, an attacker can type input that closes a quote early and appends their own SQL. Suddenly “look up this username” becomes “look up this username, then dump the table,” depending on the app’s carelessness.

What actually prevents it

• Parameterized queries / prepared statements (almost always the answer)
• ORM APIs that do not reintroduce raw string concatenation
• Least-privilege database accounts (injection should not mean full DBA)
• Input validation as defense-in-depth — not as the only door lock

What does not prevent it by itself

• “We blacklist the word SELECT”
• Randomly escaping some quotes in PHP and hoping
• Hiding error messages while still concatenating SQL

Why this belongs on Mosfetti

Many of us host forums, client WordPress sites, small apps, and homelab dashboards. Injection is not abstract cybersecurity theater — it is how a forgotten plugin turns into a database breach.

Discussion

If you review code for friends or clients, what is the fastest way you spot “this query is one quote away from disaster”?