CSV exports: check formulas before opening data in a spreadsheet

Let's discuss your project →

A CSV file can look harmless because it is plain text. The risk appears later, when that text is opened in a spreadsheet application that may interpret some cells as formulas. OWASP describes this as CSV injection, also called formula injection, and the key lesson is simple: the file format alone does not make an export safe when the input is untrusted. OWASP

For teams that export reports from a CRM, help desk, internal back office, or custom business app, the useful question is not whether CSV is dangerous in the abstract. The useful question is: where will the file be opened, and which values could be treated as formulas by the recipient’s software?

Where the risk actually starts

OWASP notes that in spreadsheet tools such as Excel and LibreOffice Calc, cells beginning with = may be evaluated as formulas. The page also flags other leading characters that can matter in some contexts, including +, -, @, tab, carriage return, and line feed. So the risk is not the CSV container by itself; it is the combination of untrusted content and a downstream program that interprets that content in a special way. OWASP

That is why a partial fix is often not enough. Sanitising the web form, escaping quotes, or changing the way the backend stores a value may still leave the downloaded export exposed if the spreadsheet application reinterprets the first character in a cell.

What to confirm before you test

Before anyone checks an export, three things should be clear:

  1. The real export path used in daily work.
  2. The actual spreadsheet software the recipient opens the file with.
  3. Synthetic test data only, never production customer records.

This is a defensive validation exercise, not a universal proof that one rule will work everywhere.

A safe validation workflow

1) Map the full data path

Pick one field that is clearly text, such as product_name, ticket_subject, or comment. Then answer these questions:

  • Who enters the value?
  • Does it come from external users or internal staff?
  • Is it exported unchanged, transformed, or cleaned before download?
  • Is the CSV opened by a spreadsheet application?

If the answer to the last question is yes, the control has to be tested on the exported file, not only on the application form.

2) Use one harmless test value

In an isolated test environment, place a minimal synthetic value such as =1+1. The goal is not to execute an attack. The goal is to see whether the spreadsheet treats the cell as text or as a formula.

You can repeat the same check with a few other leading characters mentioned by OWASP, plus separators and empty cells, to see whether the export preserves the intended meaning of the data.

3) Open the file in the real recipient tool

Open the CSV in the same spreadsheet software your users actually rely on. If the business process includes saving and reopening the file, repeat that full cycle as well. OWASP warns that some protections may behave differently after a file is saved and reopened, so the test should match the real workflow instead of stopping at the first view. OWASP

A didactic example

Simulated input:

  • column: comment
  • value: =1+1

Expected result in a test environment:

  • the cell remains visible as text, not evaluated as a formula;
  • the exported meaning stays readable for the authorised recipient;
  • no unexpected side effects appear in adjacent columns.

This is a teaching example, not a penetration test performed here.

Choosing a mitigation without overselling it

OWASP is explicit that there is no universal sanitisation rule that is safe for every spreadsheet and every downstream consumer. In practice, the mitigation has to fit the use case. A CSV designed for human review may need a different approach from a file that is immediately reimported by another system. OWASP

For Excel, OWASP describes a stronger approach: prepend a tab to cells that start with formula-triggering characters. The trade-off is also important: the tab remains in the data. That makes this option more suitable when the file is primarily for human consumption, and less straightforward when the CSV must remain machine-friendly. OWASP

Acceptance checks worth keeping

A control is useful when all of the following are true:

  • the export path has been mapped from source to final file;
  • the harmless test produces the same result in the recipient’s real software;
  • there is a documented rule for text columns that may be exposed to untrusted input;
  • the test is repeated after every change to the export logic.

Suggested responsibilities:

  • development/backend: implement the export rule;
  • IT/security: validate the behaviour in the actual recipient tool;
  • operations or editorial staff: keep the test case and checklist current.

What to do next

If your team exports CSV reports from internal systems, review the full path before publishing the file. A small test on the real workflow is usually more valuable than a generic list of “dangerous” characters.

If you want a practical starting point, choose the most-used export first, typically the one sent from administration, support, or customer operations. From there, you can build a repeatable check and decide where a specific export protection is really needed.

Sources