A small e-commerce site has a login form with username and password fields. The developer wrote the authentication query as a string concatenation: SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'". There is no input validation — the application takes whatever the user types and places it directly into the SQL query.
An attacker enters ' OR '1'='1 in the username field and anything in the password field. The resulting query becomes: SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'anything'. Because '1'='1' is always true, the condition is satisfied for every row in the database. The query returns all user records, and the application authenticates the attacker as the first user — typically the administrator account.
The fix requires two things: input validation (reject usernames containing single quotes and SQL keywords) and parameterized queries (separate query structure from data entirely, so user input can never be interpreted as SQL). Input validation alone reduces attack surface; parameterized queries eliminate the injection vulnerability at its root.
A traveler logs into a project management application from the hotel Wi-Fi. The application serves its login page over HTTPS, but after authentication it sets the session cookie without the Secure attribute and also serves some pages over plain HTTP. The session cookie is: Set-Cookie: session=a8f5f167f44f4964e6c998dee827110c — no Secure flag, no HttpOnly flag.
An attacker on the same hotel Wi-Fi is running a passive network capture. When the traveler navigates to an HTTP page within the application, the browser sends the session cookie in the request headers — unencrypted, in plaintext. The attacker captures the session token.
The attacker pastes the captured session cookie into their own browser using developer tools. The application accepts it — the session token is valid. The attacker is now authenticated as the traveler without ever knowing the password. They can read project data, send messages as the traveler, and access anything the traveler's account can reach.
The fix: set the Secure attribute on all session cookies so the browser never transmits them over HTTP. Also set HttpOnly to prevent JavaScript from reading the token. Serve the entire application over HTTPS — not just the login page.
A development team runs their C application through a SAST tool before release. The tool produces a report with 23 findings. Finding #1 flags line 847: a call to gets(buffer) to read user input. The SAST tool notes that gets() does not check buffer length and recommends replacing it with fgets(buffer, sizeof(buffer), stdin). The developer fixes this — a genuine buffer overflow vulnerability is eliminated.
Further down the report, findings #14–17 are false positives: the tool flagged a custom string handling function as potentially unsafe, but review confirms the function correctly validates length before any write operation. The developer marks these as false positives and moves on.
What the SAST tool does not flag: the application's password storage module uses MD5 to hash passwords without salting. MD5 is in the code, and SAST could flag it as a deprecated algorithm — but the tool in this case only flags known-unsafe function calls, not algorithm choices. Even if it did flag MD5, a more subtle issue is present: the implementation stores the MD5 hash but never adds a salt, making it vulnerable to rainbow table attacks. The "correct" implementation of an insecure algorithm, from a code pattern perspective, looks like valid code.
A software vendor distributes a popular network monitoring tool. An attacker compromises a third-party download mirror that hosts the installer. The attacker replaces the legitimate installer with a modified version that includes a remote access trojan embedded in the setup package alongside the legitimate software.
An IT administrator downloads the installer from the compromised mirror. When they double-click the file, Windows Authenticode runs before the installer executes. It extracts the code-signing signature from the file, decrypts it using the vendor's public key (from the CA-issued certificate), and computes a fresh hash of the installer binary. The hashes do not match — the file was modified after signing.
Windows displays a security warning: "Windows cannot verify the publisher of this driver software" / "The digital signature of this file cannot be verified." The administrator sees the warning, recognizes that the installer failed signature verification, does not proceed, and reports the incident. The download mirror is investigated and the compromised file is removed.
Without code signing, the tampered installer would have appeared identical to the legitimate one — same file name, same approximate size, similar behavior during installation. Code signing is the mechanism that makes this attack detectable without running the software.
A user on a smartphone visits a malicious website that exploits a zero-day vulnerability in the mobile browser's JavaScript engine. The attacker achieves code execution within the browser process. From the attacker's perspective, they now control the browser app running on the device.
The attacker attempts to read the user's stored passwords from the password manager app. The mobile OS sandbox blocks this: the browser app has no permission to access another app's data storage. The attacker attempts to read emails from the mail client. Also blocked — separate sandbox. The attacker attempts to silently enable the microphone. The permission system requires explicit user grant; the browser was not granted microphone access.
What the attacker can access: the browser's own data — browsing history, cached pages, stored browser cookies, browser-saved autofill data. The damage is real, but it is bounded by the browser's sandbox. Without sandboxing, code execution in the browser would grant access to the entire device filesystem, all other app data, and all hardware.
The user and security team are alerted by the device's security monitoring. The browser process is terminated. Because the compromise was sandboxed, there is no persistence mechanism outside the browser — reinstalling the browser app eliminates the attacker's foothold.