CSV looks simple, but a file can be structurally valid and still contain values that behave unexpectedly when opened in spreadsheet software.
CSV syntax is not the whole story
CSV itself does not define formulas. A parser may see =1+1 as an ordinary string, while spreadsheet software may interpret the same value as a formula after import.
id,value
1,=1+1
2,+10+20
3,@SUM(A1:A2)
Nothing in that example is necessarily malformed CSV. The risk appears later, when another application decides how to interpret the cell value.
Why this matters
Formula-like values matter most when CSV data contains user-controlled or externally supplied content. Typical sources include form submissions, CRM exports, support tickets, marketplace data, and administrative reports.
username,comment
alice,Looks good
bob,"=HYPERLINK(""https://example.com"",""Click"")"
A parser can accept this file while a spreadsheet application may treat the second row differently from plain text.
Characters worth checking
Common spreadsheet formula-triggering prefixes include:
=
+
-
@
A match is not automatically malicious. -12 may be a negative number, and +44 may be part of a phone number.
Spreadsheet behavior also varies by application and locale. Security guidance such as OWASP's CSV Injection material additionally calls out tab, carriage return, line feed, and some full-width variants as cases worth considering.
That is why reporting the risk and testing against the target spreadsheet application is usually better than assuming one universal rule.
Why automatic sanitization can be risky
One defensive technique is to prefix a value with an apostrophe. That may force some spreadsheet applications to treat the value as text, but it also changes the original dataset.
For exports, migrations, and audit data, silent rewriting may be undesirable. Some spreadsheet applications may also transform quoting or escaping when a CSV file is saved and reopened.
A safer workflow is:
- parse the CSV;
- identify formula-like cells;
- show the row, column, and original value;
- let the user decide whether the value is intentional;
- apply a mitigation appropriate to the target spreadsheet application.
Formula risk is different from malformed CSV
An unclosed quote is a structural CSV error. A quoted value such as "=1+1" can still be structurally valid while remaining interesting from a spreadsheet-risk perspective.
Successful parsing does not guarantee safe downstream interpretation.
Takeaway
A CSV file can be valid and still contain values that downstream software interprets in surprising ways.
Reference
Originally published on DataToolForge.
AI-assisted disclosure: I used AI as a drafting/editing assistant and reviewed the technical content before publication.
Top comments (2)
The distinction between valid CSV and safe spreadsheet output is useful. I'd make the preflight report export-path-specific: a value like +44 should be flagged as a possible formula only when that column is headed for a spreadsheet, without rewriting the original import. Would you also test the mitigated file after opening, saving, and reopening it in the target spreadsheet app? That round trip seems like where a one-time escape can stop holding.
That's a good point. I currently treat formula-like prefixes as a preflight warning rather than rewriting the source data, but making the warning export-target-aware would reduce false positives for values like +44.I also agree that testing only the first open is not enough. An open → save → reopen round trip in the target spreadsheet app is a better way to verify whether a mitigation actually survives spreadsheet normalization.I'm planning to add this kind of round-trip test to the CSV Import Preflight test cases, especially for Excel and Google Sheets. Thanks for pointing it out.