CSV injection, also called formula injection, happens when a CSV export contains text that someone else typed, such as a name or a form answer, and that text begins with a character like = so a spreadsheet treats it as a formula when the file is opened. The fix belongs mainly to whoever generates the export, but anyone who receives CSV files can check them first. CSVPrune from Automata Labs is an offline CSV viewer and cleaner where you can inspect the raw values and search a column for risky leading characters before the file ever reaches Excel.
Open, inspect and clean CSV exports on your own PC, with no uploads and no network calls.
Get it fromMicrosoft
What is CSV injection?
The OWASP page on CSV Injection describes a boundary problem: an application exports untrusted text, then a spreadsheet interprets that text as a formula rather than displaying it literally. CSV itself does not execute anything; the receiving spreadsheet decides how to interpret each cell.
So if a website lets anyone type into a “Company name” field, and an admin later exports all sign-ups to CSV and opens it in a spreadsheet, whatever was typed into that field arrives in a cell. If it begins with a formula character, the spreadsheet may evaluate it.
Why is formula injection dangerous?
OWASP identifies risks involving spreadsheet vulnerabilities, users dismissing security warnings, and disclosure of spreadsheet data. These are reasons to inspect exports and keep spreadsheet software updated, not reasons to enable unfamiliar formulas or external connections.
The warning problem is the human one. A warning in a file from a stranger looks suspicious. The same warning in a file you exported from your own admin panel can look routine. The file’s trusted origin does not make every form answer inside it trustworthy.
The application should handle untrusted fields safely when exporting, and recipients should keep import safeguards enabled. Neither side should assume the other has made arbitrary text safe to evaluate.
Which characters trigger formula injection?
OWASP identifies the following leading characters for review. Interpretation depends on the spreadsheet and locale; finding one is a review signal, not proof that a cell is malicious:
| Character | Name | Note |
|---|---|---|
| = | Equals | OWASP’s main example of a formula start |
| + | Plus | On OWASP’s list |
| - | Minus | On OWASP’s list, and also used by negative numbers |
| @ | At | On OWASP’s list |
| 0x09 | Tab | On OWASP’s list of characters a cell should not begin with |
| 0x0D | Carriage return | On OWASP’s list of characters a cell should not begin with |
| 0x0A | Line feed | On OWASP’s list of characters a cell should not begin with |
| Full-width equals, plus, minus and at | Double-byte variants | Can be treated as formula starts in some locales, according to OWASP |
Checking only the beginning of the original input is insufficient. Incorrect handling of separators or quotes can change the cell boundaries when the CSV is imported. Validate the exported fields after proper CSV parsing, not just the original form answers. Our guide to RFC 4180 quoting rules explains how commas, quotes and line breaks define where cells begin.
How do you prevent CSV injection when generating an export?
OWASP describes two approaches, each with caveats. CSV quoting alone preserves field boundaries; it does not guarantee that a spreadsheet will treat a field as text.
Quote and prefix. One approach encloses fields in double quotes, prefixes their content with a single quote, and doubles embedded double quotes. The goal is literal text interpretation. OWASP warns that Excel can remove quoting or escape characters when saving a CSV, so a saved and reopened copy may interpret a previously escaped value differently.
Tab prefix inside the quoted field. OWASP also describes prefixing formula-leading fields with a tab inside the quoted field for Excel-oriented exports. This is observed application behavior, not a cross-spreadsheet guarantee. The tab remains data, which can change matching, validation and downstream programmatic imports.
There is no single transformation suitable for every spreadsheet and every data consumer. Define the intended import workflow, test it with harmless values in the actual application, and check a saved and reopened copy. Keep original data separately when a spreadsheet-oriented export adds prefixes.
How do I check a CSV file for formula injection before opening it?
If you receive exports rather than build them, a little caution goes a long way:
- Do not double-click it into a spreadsheet first. Open it in a viewer that shows raw text values rather than evaluating imported formulas.
- Look at free-text columns. Names, comments, addresses and form answers are where outside input lands. System-generated IDs and dates still need validation if outside input can influence them.
- Search parsed cells for risky leading characters. A regular expression such as
^[=+@\t\r\n]finds cells that begin with equals, plus, at, tab, carriage return or line feed. Check a leading minus and the full-width variants separately. This is a first-pass review pattern, not a complete detector or a safety certificate. - Check how embedded separators and quotes were exported. A comma inside correctly quoted text is ordinary data; broken quoting can create an unintended cell boundary.
- Use explicit text-import controls where available. Import untrusted text columns as Text and check how the intended spreadsheet handles a saved and reopened copy.
- Treat spreadsheet warnings seriously, even in files from your own systems. Do not enable unfamiliar formulas or external connections to make an import work.
| Column type | Typical risk | What to do |
|---|---|---|
| System IDs and timestamps | Low | Spot check |
| Numeric amounts | Leading minus is normal | Check that values are numbers, not text |
| Names, comments, addresses | Higher | Search for leading formula characters |
| Phone numbers | A leading plus is common | Decide whether to keep them as text |
Why do phone numbers and negative numbers complicate this?
Because the same characters are legitimate data. International phone numbers often start with +, and negative amounts start with -. Prefixing cells may prevent formula interpretation in a tested spreadsheet workflow, but it also changes the data and can break a CRM or accounting import. It is not a universal protection. Review values per column and preserve legitimate phone numbers as text and legitimate amounts as validated numbers.
How does CSVPrune help with suspicious CSV exports?
CSVPrune is a CSV cleaner, viewer and converter for Windows that runs entirely on your PC. Its documented features include:
- Opening large exports in a searchable, filterable and sortable grid.
- Column-scoped find and replace with plain text or regular expressions, useful for the first-pass review above.
- Column profiling to identify invalid values and data-quality issues.
- Whitespace cleanup and standardization of text, numbers, dates and booleans.
- Masking sensitive fields such as emails, phones and IDs when sharing.
- Reusable recipes for applying the same cleaning steps to recurring exports.
- Export to CSV, JSON or XLSX.
- Local processing without uploads, telemetry or network calls.
Review the final exported copy after cleaning. Trimming whitespace or changing text can alter which character is first, and exporting as XLSX is not itself proof that imported strings remain inert.
Search any column with regex and see exactly what an export contains before it reaches a spreadsheet.
Get it fromMicrosoft
To be clear about scope: CSVPrune’s listing does not describe a dedicated formula-injection scanner or an automatic sanitizer, and no viewer replaces fixing the export at its source. What it gives you is a private place to inspect, search and clean values. If the same export also needs personal data hidden before sharing, see how to mask personal data in a CSV. For encoding and number problems that show up in the same files, see CSV UTF-8 vs CSV comma delimited and why Excel removes leading zeros.
Frequently asked questions
Is CSV injection the same as SQL injection?
No. SQL injection targets a database query. CSV injection targets the person who opens an exported file in a spreadsheet.
Does saving as XLSX fix CSV injection?
Not by itself. If a value is already a formula when the file is converted, it can stay a formula. Check the values first.
Why is a leading minus on OWASP’s list if negative numbers use it?
Because OWASP lists it among the characters a cell should not begin with, since spreadsheets can read what follows as a formula. That is why sanitization needs judgment per column.
Is a single quote prefix enough?
OWASP says the quote-based techniques are not reliable in Microsoft Excel after saving and re-opening the file.
Does CSVPrune remove dangerous formulas automatically?
Its listing does not describe that. Use column-scoped regex search and find and replace to locate and handle risky values yourself.
Try CSVPrune
Get CSVPrune from the Microsoft Store. It is a one-time purchase with no subscription, and the Store listing shows the current price.
Clean messy exports privately on your PC and save the steps as a reusable recipe.
Get it fromMicrosoft
Microsoft, Windows and Excel are trademarks of the Microsoft group of companies. OWASP is a registered trademark of the OWASP Foundation, Inc. LibreOffice is a trademark of The Document Foundation. CSVPrune is not affiliated with or endorsed by Microsoft, the OWASP Foundation or The Document Foundation.