One CRM Export, Two Jobs: Why Your Spreadsheet Download Should Not Be Your Re-Import File
One CRM Export, Two Jobs: Why Your Spreadsheet Download Should Not Be Your Re-Import File
Imagine your internal tool exports customers from your CRM as a CSV file. Someone opens it in a spreadsheet, filters it, and later wants to load the changes back in. It looks like one feature. It is really two, and treating them as one is where trouble starts.
What the source says
OWASP's page on CSV Injection (linked at the end) describes the problem like this. It occurs when a website embeds untrusted input inside a CSV file. Spreadsheet applications can interpret a cell that begins with = as a formula. Your app sees a text field. The spreadsheet sees an instruction.
A harmless example: if a customer's name field contained =1+2, a spreadsheet may show 3 instead of the text you stored. That example is trivial. The point is that the cell stopped being plain data.
OWASP also says the concern is not limited to the equals sign. It lists +, -, @, tab, CR and LF, and some fullwidth variants in some locales. It also notes that separators and quoting can create a new cell, so checking only the first character of the input is not enough.
Two more source points matter for your decision. Quotes or escaping can be lost when Excel saves and reopens a CSV, which can reactivate formulas. And OWASP states there is no universal safe CSV sanitization strategy for all spreadsheet applications and downstream consumers.
The design suggestion
What follows is my practical suggestion, not an assertion from OWASP: build two separate outputs.
1. A human download. This file exists to be read and sorted in a spreadsheet. Your developer can apply protective changes to risky cells, and you accept that the file is a presentation of the data, not the data itself.
2. A machine re-import format. This file exists to round-trip exactly. It should be treated as input to your own tool, not something people open and resave in a spreadsheet. Your importer should validate what it receives instead of trusting it.
The reason to split them is that protective changes to a cell alter its content. OWASP describes a tab technique for Excel, but it warns the behavior may differ in other applications and that the tab stays in the data, which affects machine imports. So a trick that helps the human file can damage the re-import file. One universal recipe cannot serve both, which is why I would not ask for one.
What a developer review should specify
Because the source says there is no universal strategy, the review should name its own conditions:
- The actual spreadsheet application and version your team uses.
- What happens on import, and what happens on save and reopen.
- The field structure, including fields that could contain separators, quotes or line breaks.
- Negative numbers, which legitimately begin with a minus sign, so a blanket rule on that character may corrupt real values.
- Identifier preservation, such as phone numbers or account codes with leading zeros or leading + signs.
- Which fields hold untrusted customer-entered text, such as names, notes and company fields.
A proposed acceptance test
This test is proposed, not performed. I have not run it, and it is a starting point for your developer to adapt.
Create a small test CRM with four records:
- A customer whose name is
=1+2. - A customer whose notes field contains a comma, a quotation mark and a line break.
- A customer with a phone number beginning with +43 and an account code beginning with 007.
- An invoice balance of -25.50.
Export both files. Open the human download in the spreadsheet version your team actually uses, save it, close it, and reopen it. Record what each cell shows. Then feed the machine format through your importer, without any spreadsheet in between, and compare every field to the original. The test passes when the names and notes are not interpreted as formulas in the human file, and when the re-import reproduces all four records exactly, including the leading zeros, the plus sign and the negative balance. Any difference is a finding to resolve before the feature is accepted.
Passing this one scenario would not mean the export is fully secure. It would only tell you the tested cases behave as agreed in the tested setup.
Handoff checklist
- Two outputs specified: human spreadsheet download and machine re-import format.
- Spreadsheet application and version named.
- Save and reopen behavior documented.
- Untrusted fields listed.
- Negative numbers and identifiers covered.
- Importer validates input and does not rely on the human file.
- Acceptance test above adapted, run by the developer, and results recorded.
If you are scoping an internal tool like this, you can describe your export needs through /enquire/.
Source: OWASP, CSV Injection, https://community.owasp.org/attacks/CSV_Injection (retrieved 1 November 2026)