Injection is one of the oldest tricks on the web, and it still causes some of the worst breaches. The idea behind it is simple: your app takes something a user typed, treats part of it as an instruction rather than as plain text, and does what the attacker asked. This post explains the two forms you are most likely to meet, SQL injection and cross-site scripting, without the jargon, and why apps built quickly tend to be exposed to them.
What injection actually is
Almost every app mixes two things together: instructions that you wrote, and data that a user provided. A search box, a login form, and a comment field all take input and feed it into something, usually a database query or a web page. Injection happens when an attacker types input crafted so that your app stops treating it as data and starts treating it as an instruction. The fix, in every case, is the same principle: keep the user's data and your instructions strictly separate, so that input can never change what the app was told to do.
SQL injection: talking directly to your database
Most apps store their data in a database and ask it questions using a language called SQL. If your app builds those questions by gluing user input straight into the text of the query, an attacker can type input that rewrites the question. Instead of asking for one user's record, the rewritten query might return every record, skip the password check entirely, or in the worst cases change or delete data. This is not theoretical, and it remains one of the most damaging bugs on the web. The defence is to use parameterised queries, where the database is told the structure of the question up front and the user's input can only ever be a value, never part of the instruction.
Cross-site scripting: attacking your users through your page
Cross-site scripting, usually shortened to XSS, is injection aimed at the browser rather than the database. If your app takes something a user submitted, such as a comment or a profile name, and places it into a web page without cleaning it, an attacker can submit code instead of text. When another user views that page, the code runs in their browser as if it came from you. That can steal their session, act on their behalf, or quietly redirect them. The defence is to treat all user-supplied content as text when it is displayed, and to escape it so the browser never mistakes it for code. This is closely related to access control, because a stolen session hands an attacker whatever that user was allowed to do.
Why fast-built apps get this wrong
Modern frameworks actually protect against a lot of injection by default, which is genuinely good news. The trouble starts at the edges, where a developer reaches for a raw query to do something the framework made awkward, or renders a block of user content as raw HTML to make it look right. AI coding assistants make this more likely, because they will happily produce a working feature that glues input together the direct way, and it looks finished because it works. We wrote about that pattern in the security gaps AI coding tools miss, and our pre-launch checklist covers where to look before you ship.
What you can and cannot see from the outside
Injection is largely an inside-the-application problem, which makes it a good example of the limits of any external scan. A quick Surface Check can tell you about the parts that are visible from the public internet, such as whether your traffic is encrypted and whether obvious information is leaking, but it cannot safely probe your login form or your search box for injection without permission, because doing so means sending crafted input at a live system. Finding these reliably means reviewing the code and testing with authorisation, which is exactly the gap we describe in what your Surface Score does and does not mean. For a deeper reference, OWASP maintains a clear injection prevention cheat sheet.
Next steps
Start with the free Surface Check to clear what is visible from outside, then look hard at every place your app takes user input and feeds it into a query or a page. If you want that done properly, our application security assessment reviews injection alongside authentication, access control, and data handling, in the round rather than in isolation. We prepare the fixes and hand them to your team to review and deploy, or apply them directly where you have authorised us to do so in writing. You can get in touch through our website.