Exploitation basics: buffer overflows, SQL injection and XSS, and how to prevent them

Most successful attacks exploit a mistake in software. Three classes of mistakes have been around for decades and still appear in vulnerability reports every year: buffer overflows, SQL injection and cross-site scripting (XSS). This lesson explains how each works in principle and, more importantly, how developers and defenders prevent them. It deliberately contains no attack code: understanding the idea is enough to recognise and fix the flaw.

All three share one root cause: a program treats data from outside as if it were trustworthy. Input that should only ever be data ends up being interpreted as instructions, whether by the processor, the database or the browser.

Buffer overflows

A buffer is a fixed-size area of memory reserved to hold data, such as a name typed into a form. If the program copies more data into it than it can hold without checking the length, the extra bytes spill over into neighbouring memory. MITRE’s Common Weakness Enumeration calls this a classic buffer overflow (CWE-120). Depending on what gets overwritten, the result ranges from a crash to an attacker redirecting the program to run code of their choosing.

Overflows mostly affect languages such as C and C++, which let programmers manage memory directly. Defenses work in layers: memory-safe languages (Swift, Rust, Go, Java) that check bounds automatically; careful length checks in older code; and operating-system protections such as address space layout randomisation and non-executable memory, which make exploitation much harder even when a bug exists. Apple’s platform security guidance describes several such protections, and Apple silicon adds hardware features like pointer authentication.

SQL injection

Many applications build database queries by combining a fixed query with something the user typed, such as a search term or a username. If the input is pasted straight into the query text, a carefully crafted input can change the query’s meaning, for example to return every record instead of one, or to modify data. This is SQL injection, CWE-89, and it has caused some of the largest data breaches on record.

The fix is well known and reliable: parameterised queries, also called prepared statements. The query structure is sent to the database separately from the data, so input can never be interpreted as part of the command. The OWASP SQL Injection Prevention Cheat Sheet recommends this as the primary defense, supported by least-privilege database accounts and input validation.

Cross-site scripting (XSS)

XSS happens when a website includes content from one user in a page shown to another user, without neutralising it. If that content contains script, the victim’s browser runs it as if it came from the trusted site. From there it can read what the page shows, act as the logged-in user or steal session information. CWE-79 describes this weakness, and it comes in stored, reflected and DOM-based variants depending on where the untrusted content enters the page.

The OWASP Cross-Site Scripting Prevention Cheat Sheet centres on output encoding: whenever untrusted data is placed into a page, encode it for that exact context (HTML text, an attribute, JavaScript, a URL) so the browser treats it as text, not code. Modern web frameworks do much of this automatically, and a Content Security Policy adds a second layer by limiting which scripts a page may run at all.

The pattern behind all three

The OWASP Top 10 groups injection flaws among the most critical web application risks, and CISA’s Secure by Design campaign pushes software makers to eliminate whole classes of these bugs rather than patch them one at a time. For testers, finding one of these flaws is only half the job; the report should explain the root cause so developers fix the pattern, not just the single instance.

What this means for users

You cannot fix a vendor’s code, but you can shrink the window between a fix and your safety: install updates promptly, especially for browsers and anything facing the internet. FireAI flags apps on your Mac that need a security update, and asks before a new or modified program goes online, which limits what a successfully exploited app can do on the network.