DEV Community: Tarun Jaswani

Your 'Export to CSV' Button Is a Security Hole. CSV Injection Explained for Developers Who DiDn't Know This Existed.

Tarun Jaswani — Fri, 24 Jul 2026 14:12:54 +0000

You built an application that accepts user input — names, comments, form responses, whatever. Somewhere, there's an 'Export to CSV' or 'Download as Excel' button that lets an admin or user pull that data into a spreadsheet. Perfectly normal feature, built by thousands of apps. And if you're not sanitising that user input before it hits the export, you've built a weapon aimed at whoever opens the file.
▸ https://github.com/tarunjaswani
CSV injection is an attack where a malicious user enters a crafted string into a data field — something that looks harmless in your application's UI, but becomes a live formula when opened in Excel or Google Sheets. The spreadsheet application executes it as code, not data. And the victim isn't your server; it's the person who clicked 'Export' and opened the file, usually an admin or internal team member.
▸ https://github.com/tarunjaswani/CSV-Injection/tree/main
How It Actually Works
Spreadsheet applications like Excel and Google Sheets treat cell contents that begin with certain characters as formulas to execute. The dangerous characters are: = (equals), + (plus), - (minus), @ (at), and sometimes tab and carriage return. If a user enters a string beginning with one of these into a field your application stores and later exports to CSV, the spreadsheet application interprets it as a formula — not as the text string you intended it to be.
The classic demonstration: a user enters =cmd|'/C calc'!A1 as their 'name' in a form. Your app stores it as text. An admin exports the data to CSV and opens it in Excel. Excel sees the = at the start, interprets the rest as a DDE (Dynamic Data Exchange) command, and — if the user clicks through the warnings — executes a system command on the admin's machine.
More practically, the same mechanism can be used to exfiltrate data from the spreadsheet itself, make web requests to attacker-controlled servers (leaking information about who opened the file and from where), or trigger actions the opener didn't intend.
▸ https://x.com/TJaswani7857
Why Developers Miss It
• It doesn't attack the server. Traditional security thinking focuses on protecting the server — SQL injection, XSS, authentication bypass. CSV injection bypasses the server entirely; the attack surface is the exported file and the software that opens it.
• The input looks harmless in the application. A string starting with '=' displays fine in a web UI, in a database, in an API response. It only becomes dangerous when it lands in a spreadsheet context — a context the developer wasn't thinking about when they built the input handler.
• It's not in the OWASP top 10 (as its own category). It's a form of injection, but it doesn't get the headline attention that SQLi or XSS do, so most security training skips it entirely.
How to Fix It

Sanitise on output, not just on input. When writing data to a CSV export, prepend a single quote (') or a tab character before any cell value that begins with =, +, -, @, or tab. The single quote tells Excel to treat the cell as text, not a formula. This is the most reliable fix.
Wrap values in double quotes and escape existing double quotes. Proper CSV quoting prevents some interpretation, though it alone doesn't stop all spreadsheet formula execution.
Consider the export format. Exporting as .xlsx with a library that explicitly sets cell types to 'text' is safer than raw CSV, because you control how the spreadsheet interprets each cell.
Never assume user input is safe for any context you haven't tested. Your input validation probably checks for SQL injection and XSS. It probably doesn't check for spreadsheet formula injection. Add it.
Warn users about opening exported files from untrusted data sources. If your export contains user-supplied data from external or untrusted sources, a warning in the export or in the documentation is a defence-in-depth measure. ▸ https://medium.com/@rajkarar814/how-cybersecurity-can-change-the-world-dd4cd368c346 The Broader Point for Developers CSV injection is a specific example of a general principle: data is only safe in the context you validated it for. You validated user input for your web UI (hopefully). You validated it for your database queries (hopefully). But you didn't validate it for the spreadsheet that an admin will open after clicking 'Export' — because you weren't thinking about spreadsheets when you wrote the input handler. Every time data crosses a context boundary — from web to database, from database to CSV, from CSV to spreadsheet — the question 'is this safe in the new context?' needs to be asked again. The bug isn't in the CSV. It's in the assumption that safe-in-one-context means safe-in-all-contexts.

Your 'Export to CSV' button takes user input your app treated as text and hands it to a spreadsheet that treats it as code. The fix is a few lines of output sanitisation. The lesson is bigger: data that's safe in one context can be dangerous in the next, and the boundary between 'stored in a database' and 'opened in Excel' is a boundary most developers never think to guard.
— Tarun Jaswani

Your CORS Configuration Is Probably Broken. Here's What Attackers See When It Is.

Tarun Jaswani — Fri, 24 Jul 2026 14:07:35 +0000

If you've built anything with a frontend that talks to a backend API, you've met CORS. And if you're like most developers, you met it as an error in the browser console that blocked your own legitimate request, and you fixed it by making the policy as permissive as possible until the error went away. That 'fix' may have opened your API to any website on the internet, and you'd never know unless someone tested for it.
▸ https://github.com/tarunjaswani
Cross-Origin Resource Sharing is the browser mechanism that controls which websites can make requests to your API. When it's configured correctly, it's a powerful boundary. When it's misconfigured — which it almost always is, because the error messages push developers toward permissiveness rather than precision — it becomes one of the most common, most exploitable web security weaknesses. This article shows you both sides: the developer's mistake and the attacker's opportunity.
▸ https://github.com/tarunjaswani/CORS-Misconfiguration/tree/main
What CORS Actually Does (in One Paragraph)
When a browser on site A makes a request to an API on site B, the browser asks site B's server: 'Are you okay with site A reading your response?' The server answers via HTTP headers — specifically, Access-Control-Allow-Origin. If the server says yes to site A, the browser releases the response. If it says no (or says nothing), the browser blocks the response from reaching the JavaScript. This is the entire mechanism. CORS is the server telling the browser which external sites are allowed to read its responses.
How Developers Break It
MISTAKE 1 — ALLOW-ORIGIN: * ON AUTHENTICATED ENDPOINTS
The wildcard '*' means 'any website on the internet can read this response.' For truly public data — a public API with no authentication, serving non-sensitive data — this is fine. For anything behind authentication, it's a disaster. If your authenticated API returns Access-Control-Allow-Origin: *, any malicious website a user visits can make authenticated requests to your API (using the user's cookies) and read the response. The browser sends the cookies; the wildcard lets the malicious site read what comes back.
MISTAKE 2 — REFLECTING THE ORIGIN HEADER WITHOUT CHECKING IT
A common pattern: the server reads the Origin header from the incoming request and echoes it back in Access-Control-Allow-Origin, so every requesting site gets 'allowed.' Developers do this because it 'works' for every frontend they test. An attacker sees it too: their site sends a request with their origin, the server echoes it, and the browser says 'allowed.' It's a wildcard with extra steps.
▸ https://x.com/TJaswani7857
MISTAKE 3 — TRUSTING SUBSTRINGS OR REGEX POORLY
Some configurations check whether the origin contains or starts with a trusted domain. An attacker registers a domain like 'trusted-site.com.evil.com' or 'evil-trusted-site.com' and the check passes. Substring matching on security boundaries is a recurring source of bypasses in CORS, CSP, and URL validation alike.
What an Attacker Does With a Broken CORS

Finds the misconfiguration. Send a request with a test Origin header and check whether the response reflects it or returns a wildcard with credentials allowed. This takes seconds and is trivially automated.
Builds an exploit page. A simple HTML page with a few lines of JavaScript that makes a credentialed request to your API. No special tools needed — just a browser and a web page.
Hosts the page and lures a victim. If the target user visits the attacker's page while logged into your app, the browser sends their cookies to your API, the API responds, and the attacker's JavaScript reads the response. User data, account details, whatever the API returns — exfiltrated silently. How to Fix It • Never use Access-Control-Allow-Origin: * on any endpoint that uses authentication or returns sensitive data. Whitelist the specific origins that need access and return only those. • Don't reflect the Origin header blindly. Maintain an explicit allowlist of trusted origins and check against it exactly — not with contains, startsWith, or regex that can be tricked. • Set Access-Control-Allow-Credentials: true only when you've verified the origin against your allowlist. Credentials plus a weak origin check is the exploitable combination. • Use a CORS configuration library your framework provides rather than hand-rolling headers — it's harder to make the allowlist mistakes with a well-tested library than with manual header setting. • Test your own configuration. Send requests with unexpected Origin headers and see what your server does. The tool linked below automates this check.

CORS errors in development push you toward the permissive fix. The permissive fix, shipped to production, opens your API to any website on the internet. The gap between 'it works in development' and 'it's secure in production' is exactly one misconfigured header — and most teams never check it after the console error disappears. Check yours.
— Tarun Jaswani

The Vulnerabilities You're Probably Shipping Right Now — and How to Stop, in Plain Developer Terms.

Tarun Jaswani — Fri, 03 Jul 2026 10:27:35 +0000

Here is the uncomfortable truth about most security breaches: they are not the work of shadowy geniuses defeating brilliant defenses. They are the result of the same small set of ordinary, well-understood coding mistakes, made over and over, in codebase after codebase. The attacker rarely needs to be clever. They just need to find the one place where a developer trusted input they shouldn't have, or left a default in place, or concatenated a string that should have been parameterised.
That is genuinely good news, because it means securing your code is not about becoming a security expert. It is about recognising a handful of recurring patterns and applying their equally well-understood fixes. This article walks through the vulnerabilities most likely to be sitting in your code right now — the ones that actually get exploited — explained from a developer's point of view, each with the concrete habit that prevents it. No exploit code, no attacker playbook: just what the bug is, why it happens, and how to not ship it.
The One Idea Underneath Almost Every Vulnerability
Before the specifics, internalise the single principle that explains the majority of them: never trust input, and never mix untrusted data with commands. Almost every major class of vulnerability is a variation on data from outside your program being treated as if it were safe — as if it were code you wrote, a value you controlled, or a user you'd verified. The moment untrusted input is allowed to change what your program does rather than just what it processes, you have a vulnerability. Hold that idea and the specific bugs below become instances of one mistake.

KEY The mental model
Treat every piece of data that originates outside your code — user input, URL parameters, headers, uploaded files, API responses, anything — as hostile until proven safe. Your job is to keep that untrusted data as inert data, never letting it become a command, a query, or markup. Most of secure coding is enforcing that one boundary.

1 — Injection (the untrusted string that becomes a command)
Injection is the archetype and still one of the most damaging. It happens when your code takes untrusted input and builds a command out of it — most famously a database query. If you assemble a query by gluing user input directly into a query string, a crafted input can change the meaning of the query itself, because the database cannot tell your intended query apart from the attacker's addition. The data crossed the line into becoming code.
The fix is not to try to 'clean' the input by hand — that is a losing game. The fix is to never mix data and command in the first place. Use parameterised queries (prepared statements), where the query structure and the data are sent to the database separately, so the data can never be interpreted as part of the command. Your database driver already supports this. The rule: never build a query, shell command, or any interpreted string by concatenating untrusted input — pass the input as a separate parameter, always.
THE HABIT
▸ Use parameterised queries / prepared statements for every database call, without exception.
▸ For any system command, avoid passing user input to a shell; use APIs that take arguments as a list, not a concatenated string.
▸ Treat 'I'll just sanitise it myself' as a red flag — use the library mechanism designed to separate data from command.
2 — Cross-Site Scripting (untrusted data that becomes page markup)
XSS is injection's front-end cousin. It happens when your application takes untrusted input and places it into a web page without properly encoding it, so the browser interprets attacker-supplied content as active markup or script rather than inert text. The result is that an attacker's content runs in the context of your page, in your users' browsers — able to steal sessions, act as the user, or deface the experience.
The fix is contextual output encoding: whenever you place data into a page, encode it for the context it's going into so the browser treats it as text to display, not code to run. Modern frameworks do much of this automatically — which is exactly why you should use their built-in rendering rather than bypassing it. The danger zones are the escape hatches: the functions that inject raw HTML directly. Reach for those and you have opted out of the protection your framework was giving you.
THE HABIT
▸ Let your framework render output — it encodes by default. Trust that default.
▸ Treat any 'render raw HTML' function as a security decision, not a convenience; avoid it for anything containing untrusted data.
▸ Add a Content Security Policy as a second layer, so even a slip is contained.
3 — Broken Authentication & Session Handling
This is the category where the front door is left weak. It covers everything from storing passwords insecurely, to sessions that don't expire, to letting attackers try unlimited login attempts. The common thread is that the mechanism proving who a user is can be bypassed or worn down. Because authentication guards everything behind it, a weakness here is uniquely costly.
THE HABIT
▸ Never store passwords in plain text or with fast/general-purpose hashing. Use a purpose-built password hashing algorithm (the well-known slow, salted ones) via a maintained library — never roll your own.
▸ Don't build your own auth from scratch if a vetted framework or provider will do it. Authentication is famously easy to get subtly, dangerously wrong.
▸ Enforce rate limiting and lockouts on login to stop unlimited guessing, and support multi-factor authentication.
▸ Expire and invalidate sessions properly — on logout, after inactivity, and after a password change.
4 — Broken Access Control (forgetting to check 'are you allowed?')
This is one of the most common and most under-appreciated. Authentication asks 'who are you?'; access control asks 'are you allowed to do this?' The bug is failing to check the second question on every sensitive action. The classic form: a user can access another user's data simply by changing an ID in the URL, because the server checked that someone was logged in but never checked that this particular someone was permitted to see that particular record.
The fix is to enforce authorisation checks on the server, for every request that touches protected data or actions — never assuming that because the UI didn't show an option, the user can't invoke it. The client is fully under the user's control; the only place access control counts is the server. Check permission at the point of every sensitive operation, based on the authenticated user, against the specific resource being requested.
THE HABIT
▸ Enforce every authorisation check server-side; treat client-side checks as UX only, never as security.
▸ Verify that the logged-in user owns or may access the specific resource — don't just check that they're logged in.
▸ Default to deny: no access unless explicitly granted.
5 — Security Misconfiguration & Leaky Secrets
Sometimes the code is fine and the deployment betrays it. Default credentials left unchanged, verbose error messages that leak internal details, debug mode enabled in production, overly permissive access, and — the one that burns so many teams — secrets committed to the repository. API keys, database passwords, and tokens hardcoded into source and pushed to version control are among the most common and most exploited exposures, because automated tools scan public repositories for exactly these.
THE HABIT
▸ Keep secrets out of code entirely — use environment variables or a secrets manager, and add secret patterns to your ignore files.
▸ Change every default credential and disable debug/verbose errors in production; return generic error messages to users and log the detail server-side.
▸ Scan your repo history for committed secrets; if one leaked, rotate it — removing the commit is not enough once it's been pushed.
6 — Vulnerable Dependencies (the bug you didn't write)
Modern applications are mostly other people's code — dozens or hundreds of dependencies. When one of them has a known vulnerability, your application inherits it, even though you wrote none of the flawed code. This is now one of the most significant sources of real-world risk precisely because it is invisible: the vulnerability is deep in a package you pulled in three layers down and never looked at.
THE HABIT
Based on the data across the tables in your spreadsheet, here are the links related to cyber security, categorized by their context:### 1. Cyber Persona Profile LinksIn the Persona table, a dedicated profile column for "Cyber" contains the following social media and professional profile links: * LinkedIn: https://www.linkedin.com/in/tarun-jaswani-a85b55401/

About.me: https://about.me/tarun_jaswani
GitHub: https://github.com/tarunjaswani
Minds: https://www.minds.com/tarunjaswani/### 2. Cybersecurity Articles & ResourcesThe following links point to articles, playbooks, and discussions regarding cyber security, AI security, and digital safety found in the ALL Links and Sheet9 tables: * Cybersecurity Impact: https://medium.com/@rajkarar814/how-cybersecurity-can-change-the-world-dd4cd368c346?postPublishedType=initial
AI Security Risks: https://medium.com/@t20012195/the-ai-security-problem-nobody-is-taking-seriously-enough-1fd7ea790cc5
Crypto Wallet Security: https://app.notion.com/p/The-Crypto-Wallet-Security-Playbook-38ec05c63c4380bfa07ee0c6949957dc
Hacking & Everyday Habits Discussion: https://www.wikidata.org/w/index.php?title=Talk:Q140450878&oldid=2514561359#You_Don't_Need_to_Fear_Hackers._You_Need_to_Fix_the_Six_Everyday_Habits_That_Leave_Your_Door_Unlocked.
DeFi Protocol Smart Contract Risk Evaluation Checklist: https://app.notion.com/p/A-systematic-checklist-for-evaluating-any-DeFi-protocol-before-depositing-capital-covering-smart-c-36ec05c63c4380399336f271b6458e18 ▸ Run automated dependency scanning in your pipeline so known-vulnerable packages are flagged automatically. ▸ Keep dependencies updated; unmaintained or long-outdated packages are a growing liability. ▸ Prefer well-maintained, widely-used libraries, and minimise how many you pull in — every dependency is attack surface. The Takeaway for Developers Notice what all six have in common: none required you to become a cryptographer or a penetration tester. Each is a recurring pattern with a boring, reliable, well-supported fix — parameterise, encode, hash properly, check authorisation server-side, keep secrets out of code, scan your dependencies. Security for developers is far less about heroics than about consistently applying these unglamorous habits, and using the safe mechanisms your tools already provide instead of the convenient escape hatches that opt you out of them. The most secure developers are not the ones who know the most exotic attacks. They are the ones who never trust input, never mix data with commands, and reach for the safe default every single time — so the ordinary mistakes that cause most breaches simply never make it into their code.