Safe CSV and JSON parsing: protect uploads from nasty inputs

What makes user-supplied CSV and JSON risky

User uploads are untrusted. That sounds obvious, but it changes everything. Internal data usually follows your rules because your own code produced it. Uploaded files come from unknown tools, unknown settings, and sometimes unknown intent.

CSV and JSON also look harmless because they are "just text." But text can still trigger bugs, create bad records, or sneak in content that other parts of your system will execute. Even a small file can do damage if it hits the right weak spot, like a parser edge case or a spreadsheet formula.

This turns into real business pain in a few common ways: imports crash and cause outages, bad rows quietly pollute the database, exports trigger CSV formula injection when opened in spreadsheet apps, and large uploads cause slowdowns when you load everything into memory.

"Safe parsing" doesn't mean "my code can read the file." It means you control what happens when the file is weird, hostile, or simply larger than expected. In practice, it comes down to boundaries (size, time, row count), predictable reading (streaming instead of loading everything at once), and validating each record before it touches your database.

A realistic scenario is a contact import uploaded by a customer. The file might contain a single cell with a 5 MB string, a JSON field with unexpected nesting, or a name that starts with =HYPERLINK(...). If you treat the upload like trusted input, you can end up with downtime, messy data cleanup, and a security incident.

The main failure modes to plan for

User uploads fail in a few predictable ways. Name them up front and safe parsing becomes boring instead of risky.

Malformed CSV is the classic problem. Real files often have broken quotes, extra commas, uneven column counts, or odd encodings that turn characters into gibberish. Some parsers try to guess what the user meant. That can shift columns silently and corrupt your data, or crash an import job when a single row is wildly malformed.

CSV formula injection is sneakier. Spreadsheet apps treat cells that start with =, +, -, or @ as formulas. If you later export data and someone opens it in Excel or Google Sheets, an attacker can plant a cell that runs a formula. The danger is often downstream: the human workflow.

JSON pitfalls show up differently. Deeply nested objects can hit recursion limits or spike CPU time. Huge arrays can turn a "small upload" into minutes of work. Duplicate keys are another gotcha: some parsers keep the first value, others keep the last. Attackers can use that ambiguity to bypass validation.

Memory blowups are the simplest failure mode. Reading the entire file into memory (or building a full in-memory object before validating) turns large uploads into timeouts and crashes. A 50 MB upload can become much larger once parsed.

A practical example: a "contacts.csv" upload looks fine, but one row has an unclosed quote. Your parser shifts columns, and now the email field contains parts of the address. Or a "contacts.json" includes one contact with a massive notes array and memory usage spikes.

Start with strict boundaries before you parse

Most upload bugs happen before your parser gets a chance to help. If you accept anything that looks like a spreadsheet or "some JSON," you invite edge cases you never tested.

Decide what you actually support. If a feature only needs a simple table, accept CSV and reject JSON entirely (and vice versa). Supporting fewer formats removes a lot of weird corners.

Then set hard limits that match your real use. File size is not enough. A small file can still contain a million tiny fields, and a normal-size file can expand in memory if you load it all at once.

Boundaries worth enforcing

For typical imports like contacts, a small set of guardrails does most of the work:

• Max bytes (based on your product limits)
• Max rows and max columns
• Max field length (per cell or JSON string)
• Max nesting depth for JSON
• Time limit per parse

Encoding is another common footgun. Prefer UTF-8, handle a UTF-8 BOM, and reject files that can't be decoded cleanly. Silent "best effort" decoding can turn one bad byte into a shifted delimiter problem that breaks every row.

Reject unexpected content early. For CSV, validate the header exactly (or from a small allowlist) before processing rows. For JSON, confirm the top-level shape (object vs array) and required keys before touching the rest.

Log rejections without storing sensitive content. Save metadata and reasons (file size, row count, first error line, rule that failed), but avoid keeping the raw upload.

Defending against CSV formula injection

CSV looks harmless, but spreadsheet apps treat some cells as formulas. If an attacker uploads a CSV and you later export it for someone to open, a value that starts like a formula can run. This is CSV formula injection.

The common problem isn't your parser crashing. The danger is what happens after parsing, when a human opens the data and the spreadsheet evaluates it.

A practical rule: keep the original value for storage and auditing, but create an export-safe copy for any place the value might end up in a CSV someone opens in a spreadsheet. That way you don't lose what the user sent, and you don't hand a loaded file to your team.

When building the export-safe copy, treat a cell as risky if, after removing leading spaces and tabs, it begins with any of these characters: =, +, -, or @. If it's risky, neutralize it by prefixing a single quote (') before the value in the exported CSV. Many spreadsheet apps will then display the text but not run it as a formula.

Watch out for sneaky inputs. Attackers often add leading spaces, tabs, or hidden characters so the cell looks normal but still evaluates as a formula. Decide what you consider ignorable leading characters (spaces and tabs at minimum), and apply the check to the cleaned version.

Test with payloads that often slip through:

• =HYPERLINK("example","click")
• +SUM(1,1)
• -2+3 (looks like math)
• @SUM(1,1)
• \t=1+1 (leading space or tab)

Making JSON parsing predictable with validation

User-supplied JSON isn't just data. It's untrusted input, and you want it to behave the same way every time. The goal is simple: reject surprises early, and only accept the exact shape your app expects.

Start by validating the structure before you use values: required fields, correct types, and a tight set of allowed values. If your endpoint expects something like { "email": string, "role": "admin"|"member" }, don't accept numbers, arrays, or extra objects "because they might still work." That's how edge cases become production bugs.

Put hard limits on JSON that is expensive to process

A JSON file can be small in bytes but costly to parse, like deeply nested arrays or huge strings. Set limits up front:

• Maximum nesting depth
• Maximum string length per field (especially notes, bios, and metadata)
• Maximum array length
• Maximum total keys per object

These checks keep parsing predictable and protect memory and CPU.

Treat duplicate keys as a problem

JSON payloads can contain duplicate keys, and parsers handle them differently (first wins, last wins, or undefined). That ambiguity can be abused to bypass validation. In most cases, reject payloads with duplicate keys so attackers can't hide a bad value behind a good one.

Also avoid "helpful" type guessing. If you need a string, keep it a string. Don't auto-convert "00123" into a number or interpret dates implicitly. It changes meaning and can break downstream logic.

When validation fails, return clear, user-safe errors like contacts[12].email must be a valid email address. Don't echo stack traces, SQL details, or internal implementation details.

Step-by-step: streaming parsing that won't crash your app

Crashes usually happen because the server tries to be "helpful" and loads the whole upload into memory. The safer pattern is: set limits first, then process a small piece at a time.

Start with a quick gate before parsing. Check the reported content type, but don't trust it. Enforce a hard max file size, and reject compressed files unless you can safely inspect them. Also set a time limit so one slow upload doesn't tie up a worker.

A practical streaming workflow

A simple flow that works for both CSV and JSON uploads:

• Pre-check boundaries: max bytes, allowed encodings, and a max row or object count.
• Stream from disk or the request body. Don't call "read all" or build a full string in memory.
• Parse record-by-record and stop when you hit hard limits (rows, fields per row, max nesting depth for JSON, max string length).
• Validate each record as you go, and collect only a small error sample (for example, the first 20 issues) plus counts.
• Write accepted data incrementally: batch inserts or push valid records onto a queue for later processing.

Don't try to "fix" broken structure while streaming. If the parser reports malformed input, stop and fail fast. Partial imports are fine only if your product clearly explains them.

For a user-friendly import, return a summary: how many records were accepted, how many were rejected, and a short list of example errors with line numbers (or JSON paths). For example: "2,431 imported, 17 rejected. Top issues: missing email, invalid date, extra columns."

Validation rules that keep bad data out

Parsing is only the first step. The real safety and quality win comes from treating every upload as untrusted and checking it against a clear contract before it touches your database.

Write down what "valid" means for your app. Keep it small and specific, and enforce it the same way for both CSV columns and JSON fields. A good contract usually covers allowed fields, required vs optional fields, type and format rules (email, phone, ISO date, currency), range limits, and length limits.

Allowlists matter because they stop surprise fields from sneaking in, like an unexpected isAdmin key in JSON or an extra role column in CSV. If a header or key isn't on the list, either reject the file or ignore the field explicitly and log it, but don't silently accept it.

Normalization should be careful and predictable. Trimming whitespace and converting TRUE to true is fine, but avoid conversions that change meaning. For dates, pick one accepted format (or a short list), normalize to one output, and be consistent.

Error messages should help users fix the file quickly. Instead of "invalid input," return something like: "Row 17, field email: expected [email protected]." For JSON, point to a path: "contacts[3].phone is missing."

Decide upfront how strict you want to be. All-or-nothing is safest for imports that must be consistent. Partial success can be better for contact lists, but it needs clear rules (what gets rejected, how many errors you return, and what you store).

Common mistakes and traps to avoid

Most upload bugs aren't one big vulnerability. They're a chain of small assumptions.

A common trap is parsing everything first and only then running checks. By the time validation fails, bad data may already be in memory, written to a temp table, or passed into business logic. Treat validation as part of parsing: reject early, and stop reading as soon as you know the file isn't acceptable.

Another easy mistake is trusting the file name. Someone can upload a file called contacts.csv that's actually something else, or a CSV so malformed your parser behaves in odd ways. Inspect the content (headers, delimiters, first bytes) and enforce a small allowed shape before you commit to processing.

A few traps show up again and again:

• Letting a library auto-detect types without limits. Guessing can turn weird inputs into huge numbers, dates, or NaN values.
• Re-exporting raw CSV without formula protection. Storing =HYPERLINK(...) is one thing; exporting it for a teammate to open is where it becomes dangerous.
• Loading the whole file to "get better errors." A single oversized upload can cause memory spikes and timeouts.
• Returning massive error reports. Listing every bad row for a huge file can create a second memory problem and leak sensitive fragments.

A realistic example: you import a "leads.csv" and return a detailed error per row. An attacker uploads a huge file with tiny mistakes on every line. Your server spends minutes collecting errors, builds a multi-megabyte response, and times out.

Quick safety checklist for CSV and JSON uploads

If you want safe CSV and JSON parsing, assume the file is hostile. Most upload bugs aren't clever hacks. They're simple inputs your code didn't expect: huge files, weird encodings, or fields that look harmless but trigger behavior in other tools.

Keep a short checklist as a gate before data reaches your database:

• Set hard limits: max bytes, max rows or objects, max columns or fields, and (for JSON) max nesting depth.
• Parse in a streaming way so one upload can't spike memory.
• Validate structure and values: required fields, types, length limits, allowed enums, and date/number formats.
• Neutralize CSV formula injection when exporting or re-saving data.
• Fail closed: reject on parse errors, and return small, clear messages.

For JSON, "valid JSON" isn't enough. A large file with deeply nested arrays can be valid and still wreck performance. Depth limits, per-field length limits, and strict schema validation make parsing predictable.

Once it's live, monitor the basics: parse timeouts and slow parses, rejection rate by reason, and average rows or objects per upload. Those signals tell you where your limits and UX need tuning.

A realistic example: contact import that stays safe

A founder adds an "Import contacts" step to a signup flow. Users can upload a CSV from Excel or a JSON export from another tool. The goal is simple: create contact records (name, email, company) and skip anything unsafe.

One day a CSV arrives with this in the first-name column:

=HYPERLINK("example","Click me")

If your app later exports those contacts back to CSV for a teammate to open, that cell can execute as a formula. The fix isn't "sanitize later." For any field that might be written back to CSV, either reject values that begin with =, +, -, or @, or store a safe export version (for example, prefix with an apostrophe) and keep the original out of exports.

A different day, someone uploads a large JSON file. If your server reads it into memory and parses it all at once, it can freeze or crash. Instead, enforce an upload size limit, parse as a stream, process one contact at a time, and stop early when limits are exceeded (max records, max field length, max nesting depth).

What the user sees matters. The import page should provide a clear summary: how many were imported, how many were skipped, and a small sample of reasons with row numbers or JSON paths. Behind the scenes, logs should help you debug without storing personal data. Log counts, row numbers, error codes, and non-identifying fingerprints so you can spot repeats without keeping raw values.

Next steps: tighten your pipeline and get help if needed

Treat uploads like an external integration. Build a small set of guardrails you can verify.

Audit the endpoints that accept files. Look for clear size limits, timeouts, streaming parsing, and places where the file is read twice or converted into a giant string before parsing.

Keep a tiny test pack you run on every change: a malformed CSV, a CSV that tests formula injection behavior, a deeply nested JSON, a JSON with wrong types and missing fields, and a large valid file near your size limit. Those few files catch most regressions.

If you're dealing with an AI-generated codebase (especially prototypes from tools like Lovable, Bolt, v0, Cursor, or Replit), do an extra pass for missing limits, whole-file reads, and raw logging. If you want a second set of eyes, FixMyMess (fixmymess.ai) helps teams diagnose and repair broken AI-generated import flows, including adding boundaries, validation, and safer export handling.