DEV Community: Tarun Jaswani

Every Organisation Has Accounts Belonging to People Who Left. Nobody Knows How Many, Which Is the Whole Problem.

Tarun Jaswani — Mon, 07 Sep 2026 17:23:24 +0000

Onboarding is a process with an owner, a checklist and a deadline, because a new joiner who cannot work complains immediately. Offboarding has none of those things, because a departed employee whose access still works complains to nobody. That asymmetry quietly produces the largest population of unmonitored credentials in most organisations.
Security Researcher • Penetration Tester
Tarun Jaswani is an independent security researcher and penetration tester with over five years in offensive security, 100+ accepted vulnerability reports, and Hall of Fame recognition from Google, Zoho, TripAdvisor and Adafruit. He writes about security for the people who have to build and defend real systems.

Ask any organisation how many active accounts belong to people who no longer work there. Very few can answer. That is not because they are careless. It is because the systems that grant access and the systems that record employment are usually different systems, connected by a human being remembering to do something on a day when several other things were also happening. Onboarding self-corrects — a new joiner without access raises a ticket within the hour. Offboarding does not, because nothing breaks and nobody notices.
https://about.me/tarun_jaswani
An account belonging to someone who left is not automatically an insider threat. Most departures are entirely amicable and most former employees never think about the account again. It is a security problem for a different reason: it is a live credential that nobody owns, nobody monitors and nobody would miss.
https://dev.to/tarun_jaswani_e9a4c1020df/why-identity-is-the-new-security-perimeter-29c6
Why This Is Structurally Hard.
• Access accumulates from many sources. Directory accounts, SaaS applications bought by individual teams, cloud consoles, code repositories, VPN, database credentials, third-party dashboards. HR knows about the person; nobody has a complete list of what the person could reach.
• Shadow SaaS is invisible to the offboarding process. A team that signed up for a tool with a corporate card never told IT it exists, so it is not on the checklist that never existed.
• Shared and service accounts have no individual to deprovision. When someone leaves knowing the shared password, the credential is compromised and rotating it breaks things nobody has documented.
• Contractors and partners have access with no employment record to trigger a review at all.
• Personal devices retain cached sessions and tokens that survive a password reset, because revoking a session is a different action from changing a credential.
The asymmetry in one line
Onboarding failures are noisy and self-correcting. Offboarding failures are silent and permanent. Any process relying on someone remembering will therefore fail in exactly one direction, and it is the direction that matters.
The Related Problem: Access That Accumulates.
Departure is only the visible half. The larger volume issue is that access grows over a career and almost never shrinks. Someone joins support, moves to operations, then to engineering, and at each step gains what the new role needs while retaining what the old one had. After several years they hold a combination of permissions nobody would ever deliberately grant to one person.
This is where a compromised ordinary account becomes serious. An attacker phishing a long-tenured employee frequently inherits more than the current role implies — not because privileges were escalated, but because they were never removed.
https://dev.to/tarun_jaswani_e9a4c1020df/attackers-do-not-break-your-password-anymore-they-take-over-your-account-recovery-506l
What Actually Works.

Build the application inventory first. You cannot deprovision from systems you do not know exist. Reconcile expense records and single sign-on logs against your official list — the gap is your shadow SaaS.
Make identity the control point. Where an application supports single sign-on, use it, so that disabling one account genuinely removes access rather than removing one of several routes in.
Terminate sessions and revoke tokens on departure, not just passwords. An active session or a personal access token survives a password change, and both are commonly missed.
Trigger deprovisioning from the employment record automatically. Any process depending on someone remembering will eventually not be remembered.
Review access on role change, not only on exit. This is where the accumulation problem is actually solved, and almost nobody does it.
Run periodic recertification. Managers confirm, on a schedule, that each person still needs what they hold. Tedious, unpopular, and the only reliable way to catch what the automated triggers missed.
Treat shared and service accounts as inventory with owners. Every one should have a named owner, a documented purpose and a rotation schedule, or it should not exist. https://dev.to/tarun_jaswani_e9a4c1020df/secure-coding-is-more-than-fixing-vulnerabilities-32jl https://github.com/tarunjaswani/Vulnerabilities-notes The Test That Tells You Where You Stand. Pick someone who left six months ago and try to establish, concretely, whether every access they held has been removed. Not whether the directory account is disabled — whether the code repository, the cloud console, the analytics tool, the customer support platform, the shared drive, the third-party dashboard and the VPN all reflect that departure. Two things usually emerge. Something is still active, and more importantly, nobody can produce a definitive list of what to check. The second discovery is the more valuable of the two, because it is the actual finding: the organisation cannot answer the question, which means it cannot answer it for anyone else either. https://dev.to/tarun_jaswani_e9a4c1020df/lessons-every-cybersecurity-engineer-learns-from-real-world-web-applications-4pn1 Why This Matters More Than It Used To. When applications lived inside a corporate network, removing network access removed most access as a side effect. That containment is gone. Applications are reachable from anywhere, authentication is the only barrier, and an account that still works is a fully functional way in from any coffee shop in the world. Which makes the identity layer the actual perimeter, and orphaned accounts holes in it. They are also the least likely to be detected, because nobody is monitoring an account whose owner nobody remembers — there is no baseline to deviate from and no person to ask whether the activity was theirs. https://dev.to/tarun_jaswani_e9a4c1020df/why-web2-security-still-matters-in-an-ai-driven-world-16ii https://github.com/tarunjaswani/bounty-targets-data https://github.com/tarunjaswani/awesome-cybersec Where to Start If This Is All New. • List every application holding company data. Include the ones bought by individual teams. This is the foundation for everything else. • Reconcile active accounts against current employees in the three or four most sensitive systems. Expect surprises. • Disable rather than delete what you find, so you can restore quickly if something turns out to be in use. • Write the offboarding checklist and attach it to the employment record so it fires automatically. • Schedule the first access recertification and treat the completion rate itself as a security metric. https://www.linkedin.com/in/tarun-jaswani-a85b55401/ https://github.com/tarunjaswani Onboarding is a process because failing it is loud. Offboarding is an afterthought because failing it is silent, and the result is a population of live credentials nobody owns, monitors or would miss. Inventory what exists, drive deprovisioning from the employment record rather than from memory, revoke sessions as well as passwords, and review access when roles change rather than only when people leave. — Tarun Jaswani https://x.com/TJaswani7857 https://dev.to/tarun_jaswani_e9a4c1020df

TAGS

Cybersecurity #IAM #Offboarding #AccessControl #TarunJaswani #InfoSec #InsiderRisk #Identity #Governance #Security

Deleting a Password From Your Code Does Not Remove It. Git Remembers Everything, and So Does Everyone Who Cloned the Repository.

Tarun Jaswani — Mon, 07 Sep 2026 17:04:56 +0000

Someone commits an API key by accident, notices within the hour, deletes it and pushes the fix. The team considers the incident closed. It is not closed. The key is still in the commit history, still in every clone, still in every fork, and still valid — because deleting a line of code and rotating a credential are completely different actions and only one of them happened.
Security Researcher • Penetration Tester
Tarun Jaswani is an independent security researcher and penetration tester with over five years in offensive security, 100+ accepted vulnerability reports, and Hall of Fame recognition from Google, Zoho, TripAdvisor and Adafruit. He writes about security for the people who have to build and defend real systems.

This is the most common serious finding I encounter, and it is almost always discovered by accident. Not through a clever technique — by reading the repository history. A cloud access key committed during initial setup two years ago and removed the following week. A database password in an old configuration file. A payment gateway secret in a test script somebody wrote once. Each was deleted promptly and none was ever rotated, which means each is still live, still in the history, and still available to anyone who has ever had access to that repository.
https://about.me/tarun_jaswani
The mental model behind the mistake is understandable. In most systems, deleting something removes it. Version control is specifically designed to do the opposite — its entire purpose is that nothing is ever lost. That property is enormously useful and it makes a committed secret permanent by default.
https://dev.to/tarun_jaswani_e9a4c1020df/secure-coding-starts-before-the-first-line-of-code-4gbl
Why Deletion Does Not Work.
• The commit that added the secret still exists in history and can be read by anyone with repository access, including read-only access.
• Every clone taken before the deletion contains it. You cannot recall those, and you usually cannot enumerate them.
• Forks are independent copies. A public repository that was forked before the fix has distributed the secret to strangers permanently.
• Continuous integration logs, build artefacts and caches may contain it independently of the repository.
• Rewriting history to purge it is possible, disruptive, and still does not invalidate copies already taken.
Which leads to the only reliable rule: once a secret has been committed, treat it as compromised. Not possibly compromised. Compromised. The question is not whether to rotate it but how quickly.
The single rule
A secret that has ever been committed is burned. Rotate it. Cleaning the history is housekeeping — useful, but it is not remediation, and doing only that leaves a live credential in circulation.
Where Secrets Actually End Up.
REPOSITORY HISTORY
The obvious one, and still the most common. Configuration committed before someone set up environment variables. A test file with real credentials because the test needed to actually work. An environment file added before the ignore rule existed — note that the ignore rule prevents future commits and does nothing about the one already in history.
CLIENT-SIDE BUNDLES
Anything shipped to a browser or a mobile app is public, regardless of how it was compiled, minified or obfuscated. A key in a frontend build is a published key. Mobile applications are worse, because developers assume compilation provides protection and application binaries are trivially extractable.
CI AND BUILD LOGS
Pipelines print things. A verbose build step echoing an environment variable, a failing test dumping its configuration, a deployment script logging its own arguments. Build logs are frequently readable by a much larger group than the repository itself, and nobody thinks of them as a data store.
THE PLACES PEOPLE PUT THINGS TEMPORARILY
Shared documents, chat messages, ticket comments, screenshots pasted into an incident channel. These have no rotation, no expiry and no access review, and they persist for years in systems with far weaker controls than the repository everyone worries about.
https://dev.to/tarun_jaswani_e9a4c1020df/lessons-every-cybersecurity-engineer-learns-from-real-world-web-applications-4pn1
What Actually Fixes This.

Scan history, not just the current state. Run a secret scanner across the full commit history of every repository you own. Most teams doing this for the first time find something, and the something is usually still valid.
Rotate everything you find, then clean the history. In that order. Rotation is remediation; history rewriting is tidying up afterwards.
Put scanning in the pre-commit hook and the pipeline. Catching a secret before it is committed is trivially cheap. Catching it afterwards is an incident.
Move to a secrets manager rather than environment files. Centralised storage with access control, audit logging and rotation support removes the class of problem rather than policing it.
Prefer short-lived credentials wherever the platform supports them. A token that expires in an hour is a far smaller problem than a static key that lives for three years.
Set rotation schedules and actually run them. A credential that has never been rotated has an unbounded exposure window, and you have no way to know whether it leaked years ago.
Assume anything client-side is public. If a mobile app or frontend needs privileged access, the privileged call belongs on a backend you control, with the client authenticating to it. https://github.com/tarunjaswani/Vulnerabilities-notes https://github.com/tarunjaswani/CORS-Misconfiguration The Detection Question Nobody Asks. Suppose one of your keys leaked two years ago and somebody has been using it quietly since. How would you know? For most organisations the honest answer is that they would not, because credential use is rarely monitored for anomaly — only for failure. • Log credential usage with source context, so a key suddenly being used from an unfamiliar location or at an unusual hour is visible. • Alert on service credentials used outside their expected pattern. Machine credentials are highly predictable, which makes deviation unusually easy to detect. • Scope every credential to the minimum it needs. A leaked key restricted to reading one bucket is an incident; the same key with broad account access is a catastrophe. • Keep an inventory of which credentials exist, what they access, who owns them and when they were last rotated. Most organisations cannot produce this list, which is itself the finding. https://dev.to/tarun_jaswani_e9a4c1020df/why-identity-is-the-new-security-perimeter-29c6 https://github.com/tarunjaswani/awesome-cybersec A Realistic First Week.
Run a history scan across your repositories today. It takes minutes and the results are usually sobering.
Rotate every live credential the scan surfaces, starting with anything granting write or administrative access.
Add scanning to the pipeline so the next one is caught before it lands.
Write the credential inventory, even roughly. Owner, scope, last rotated.
Pick the oldest never-rotated credential and rotate it. Then set a date for the next one. https://www.linkedin.com/in/tarun-jaswani-a85b55401/ https://github.com/tarunjaswani Version control is designed so that nothing is ever lost, which means a committed secret is permanent by default and deleting the line changes nothing about that. Scan the history rather than the working tree, rotate before you tidy, move credentials into a manager with rotation and audit, and keep an inventory — because the credential you cannot name is the one you will never rotate. — Tarun Jaswani https://x.com/TJaswani7857 https://dev.to/tarun_jaswani_e9a4c1020df

TAGS

Cybersecurity #AppSec #TarunJaswani #InfoSec #SecureCoding #DevSecOps #Security #Engineering #Risk #Practice

A Clean Penetration Test Report Does Not Mean You Are Secure. I Write These Reports, and Here Is What They Actually Prove.

Tarun Jaswani — Mon, 07 Sep 2026 17:00:21 +0000

What They Actually Prove.
Organisations treat the pentest report as a verdict on their security posture. It is not. It is a record of what a specific person found, in a specific scope, within a specific number of days, using a specific set of credentials. Everything outside those four constraints is untested — and the report almost never says so loudly enough.
Security Researcher • Penetration Tester
Tarun Jaswani is an independent security researcher and penetration tester with over five years in offensive security, 100+ accepted vulnerability reports, and Hall of Fame recognition from Google, Zoho, TripAdvisor and Adafruit. He writes about security for the people who have to build and defend real systems.

The report lands, the findings are low severity, and somebody forwards it to the board with the word clean in the subject line. I have written that report. What it means is that within the agreed scope, during the agreed window, with the access I was given, I did not find anything more serious. That is a genuinely useful statement. It is not the statement most people read it as, which is that the system is secure — and the distance between those two readings is where a lot of false confidence lives.
https://about.me/tarun_jaswani
This is not an argument against penetration testing. Testing is one of the most valuable assurance activities available and I would not do this work if I thought otherwise. It is an argument for reading the report as the bounded, time-limited, human artefact it actually is.
https://dev.to/tarun_jaswani_e9a4c1020df/lessons-every-cybersecurity-engineer-learns-from-real-world-web-applications-4pn1
The Four Constraints Every Report Carries.
SCOPE
A test covers what the contract said it covers. If the scope named three applications, the fourth is untested — not secure, untested. The same applies to the staging environment nobody mentioned, the legacy admin panel on a subdomain, the mobile API that was assumed to be out of scope, and the third-party integration that sits between two in-scope systems. Attackers do not read the scope document. It is the single largest gap between what was tested and what exists.
TIME
A test is bounded by days. An attacker is not. Given ten working days I will prioritise the highest-probability paths and I will find what those paths reveal. Given six weeks I would go further, and a motivated adversary has as long as they want. A clean report on a short engagement is weaker evidence than a clean report on a long one, and the report rarely frames it that way.
ACCESS
What I was given determines what I can see. A black-box test with no credentials finds what an anonymous outsider finds. A test with one standard user account finds far more, because most serious findings live behind authentication in the authorisation layer. A grey-box test with source access finds more again. These produce very different reports on identical systems, and comparing them as though they mean the same thing is a category error.
https://dev.to/tarun_jaswani_e9a4c1020df/why-identity-is-the-new-security-perimeter-29c6
THE PERSON
This is the one nobody likes to state plainly. Two competent testers will not produce identical reports on the same target. We have different backgrounds, different instincts about where to dig, different depth in different vulnerability classes. Someone who has spent years on authorisation logic will find access control gaps that a network specialist walks past, and the reverse is equally true. The report reflects a methodology and a person, not an objective measurement.
What a clean report actually says
Within this scope, in this timeframe, with this access, this tester did not find anything more serious. Every word of that sentence is load-bearing, and removing any of them turns a useful finding into a false assurance.
What the Report Genuinely Is Good For.
• Finding real, exploitable issues before someone else does. This is the core value and it is substantial — a single access control flaw found in testing is worth the engagement several times over.
• Validating that controls work in practice rather than on a diagram. Plenty of well-designed protections fail in implementation, and testing is where that surfaces.
• Producing evidence a non-technical audience can act on. A working proof of concept moves budget in a way a risk register never has.
• Teaching your engineers something durable. The best outcome of any engagement is that the same class of bug stops appearing, which requires the team to understand the root cause rather than just apply the patch.
https://dev.to/tarun_jaswani_e9a4c1020df/secure-coding-is-more-than-fixing-vulnerabilities-32jl
What It Is Not Good For, and Gets Used For Anyway.

Proving security to a customer or a board. It proves a bounded absence of findings. Presenting it as proof of security is overclaiming on the tester's behalf, and most testers would not make that claim themselves.
Replacing a secure development process. Testing at the end finds what was built wrong. It does not stop things being built wrong, and an organisation whose entire security programme is an annual pentest is paying to be told the same things repeatedly.
Measuring improvement year on year. Different scope, different tester, different duration, different codebase. Comparing this year's finding count to last year's is comparing two different experiments and calling the difference progress.
Covering the parts of the estate nobody remembered to mention. The forgotten subdomain is the most common serious finding in scoping conversations, and it is only found when someone asks what else exists. https://dev.to/tarun_jaswani_e9a4c1020df/secure-coding-starts-before-the-first-line-of-code-4gbl How to Get More Out of the Same Engagement.
Scope by asset inventory, not by memory. Ask what is exposed to the internet and reconcile that against what you think is exposed. The gap between those two lists is frequently the most valuable output of the whole exercise.
Provide credentials, and provide several roles. Most serious findings are authorisation failures that are invisible without a logged-in session. A black-box test on an authenticated application is spending most of the budget on the least interesting part.
Ask for the methodology and the coverage notes, not just the findings. What was tested and found clean is as informative as what was found broken, and it tells you where the gaps in the engagement itself are.
Insist on root cause, not just remediation. Fixing the reported instance leaves the pattern. Ask the tester whether the same flaw class is likely elsewhere in the codebase — usually the answer is yes.
Rotate testers periodically. Different people find different things, and the second tester on a system frequently finds what the first walked past.
Retest after remediation, and treat the retest as part of the engagement rather than an optional extra. A fix that was never verified is a hope.

https://github.com/tarunjaswani/Vulnerabilities-notes
https://github.com/tarunjaswani/CORS-Misconfiguration
The Findings That Recur, Regardless of Industry.
After enough engagements the pattern becomes monotonous, and the monotony is itself useful information. The same handful of issues appear across organisations of every size and sector, which suggests the cause is structural rather than incidental.
• Authorisation enforced in the interface but not at the endpoint. The button is hidden; the API call still works. This is the single most common serious finding in modern applications.
• Object references that trust the identifier supplied by the client, allowing one user to read another's records simply by changing a number.
• Cross-origin policies loosened during development and never tightened, quietly exposing authenticated responses to any site.
• Export and reporting functions that trust stored input, treating data that arrived from a user as safe because it has been in the database for a while.
• Forgotten infrastructure — a staging environment with production data, an old admin panel, a subdomain pointing at a decommissioned service.
• Secrets in places they should not be: repository history, client-side bundles, configuration files committed years ago and never rotated.
https://dev.to/tarun_jaswani_e9a4c1020df/your-corsconfiguration-isprobably-brokenheres-whatattackers-seewhen-it-is-1944
https://dev.to/tarun_jaswani_e9a4c1020df/your-export-to-csv-button-is-a-security-hole-csv-injection-explained-for-developers-who-didnt-45p
https://github.com/tarunjaswani/XSS
https://github.com/tarunjaswani/CSP-Bypass
What Actually Reduces Risk Between Tests.
The organisations with the least alarming reports are not the ones testing most frequently. They are the ones where security has moved earlier — threat modelling before the design is fixed, authorisation checks written as a shared function rather than reimplemented per endpoint, dependency scanning in the pipeline, secrets managed rather than committed, and an asset inventory somebody actually maintains.
Testing then does what it is genuinely good at: finding the things that slipped through a process that was already working, rather than serving as the process itself.
https://github.com/tarunjaswani/awesome-cybersec
https://github.com/tarunjaswani/bounty-targets-data
https://github.com/tarunjaswani/Hackthebox-cheatsheet
A penetration test report is a bounded observation, not a verdict. It says that within an agreed scope, during an agreed window, with the access provided, one tester did not find anything worse. That is genuinely valuable and it is not the same as being secure. Scope it against what actually exists rather than what you remember, give the tester credentials, ask what was covered as well as what was found — and stop reading a clean report as a conclusion when it is a snapshot.
— Tarun Jaswani
https://www.linkedin.com/in/tarun-jaswani-a85b55401/
https://x.com/TJaswani7857
RELATED WRITING
Developer-facing security writing is published on dev.to, with vulnerability class research, testing methodology and reference material on GitHub.
https://dev.to/tarun_jaswani_e9a4c1020df
https://github.com/tarunjaswani

TAGS

Cybersecurity #PenetrationTesting #Pentest #AppSec #TarunJaswani #InfoSec #SecurityAssurance #RedTeam #Compliance #Risk

You Do Not Need Better Security. You Need to Know What You Are Actually Defending Against.

Tarun Jaswani — Fri, 07 Aug 2026 11:44:01 +0000

Most security advice is a pile of unranked instructions that leaves people either overwhelmed or falsely confident. Professionals do not work from lists. They work from a threat model — a short, honest answer to what you have, who would want it, and what they would realistically do. Here is how to build yours in an hour.
Security Researcher • Penetration Tester
Tarun Jaswani writes about technology and security for everyday people — the practical habits that keep ordinary lives safe online, explained without jargon and always from the side of the person trying to protect themselves.

Ask most people what they do for security and you get a list. Strong passwords. Antivirus. Do not click strange links. Use a VPN. Cover the webcam. Every item might be reasonable in isolation, but a list is not a strategy — it has no order, no reasoning, and no way of telling you which three things actually matter for your life versus which seven are folklore. That is why people either do everything badly or do a few random things well and assume they are covered.
https://about.me/tarun_jaswani
Security professionals do not start with a list. They start with a threat model: a structured answer to four questions about the specific situation being defended. It is not complicated, it does not require technical knowledge, and doing it once produces a personal priority order that makes every subsequent decision easier.
https://medium.com/@rajkarar814/how-cybersecurity-can-change-the-world-dd4cd368c346
Question One: What Do You Actually Have That Is Worth Taking.
Not "my data" in the abstract. Specifically: money and the ability to move it, accounts that control other accounts, identity documents that enable impersonation, private communications and photographs, professional access such as work systems or client data, and anything with sentimental irreplaceability like family photos with no backup.
Write the list. Most people are surprised by how short it is and how much of it funnels through two or three accounts. That concentration is the most useful thing the exercise reveals, because it tells you exactly where effort belongs.
Question Two: Who Would Realistically Want It.
This is where most people get security wrong in both directions. They either imagine a targeted expert adversary, panic, and give up — or they imagine nobody cares about them and do nothing. Both are wrong for almost everyone.
• Opportunistic criminals running automated attacks at scale. They do not know or care who you are. They test leaked credentials, blast phishing messages, and take whatever opens. This is the overwhelming majority of what ordinary people face.
• Scammers using social engineering — fake delivery notices, fake bank calls, fake job offers, romance and investment fraud. Their tool is your emotional state, not your technology.
• People who know you. Uncomfortable but real: an ex-partner, a family member, a colleague. They have context, physical access, and answers to your security questions. For many people this is the most likely serious threat.
• Targeted attackers with resources. Genuinely relevant if you are a journalist, activist, executive with signing authority, or someone holding significant crypto assets. Not relevant to most people, and pretending otherwise mostly produces paralysis.
https://x.com/TJaswani7857
Question Three: How Bad Is It If They Succeed.
Rank the consequences honestly, because not all compromises are equal. Losing a streaming account is annoying. Losing your primary email is catastrophic, because it resets everything else. Losing your banking app is immediately expensive. Losing private photographs may be unrecoverable in a way money is not.
Multiply likelihood by consequence and a priority order falls out on its own. High likelihood plus high consequence is where all your early effort goes. Low likelihood plus low consequence is where good advice goes to be safely ignored.
Question Four: What Are You Realistically Willing to Sustain.
A security practice you abandon in three weeks provides no protection. The correct measure of a control is not how strong it is in theory but how strong it is after twelve months of your actual behaviour. A password manager you use for everything beats a memorised scheme you abandon under pressure. Two-factor on five critical accounts that you keep enabled beats two-factor on forty accounts that you disable in frustration.
Choose controls you will still be using next year. This single filter eliminates most of the elaborate advice that circulates online, and it is why professionals recommend boring, durable measures over clever fragile ones.
https://www.linkedin.com/in/tarun-jaswani-a85b55401/
What the Model Produces for Almost Everyone.
Run those four questions for a typical person with a job, a family, a bank account, and normal public exposure, and the same short priority list emerges nearly every time:

Protect the primary email above everything, because it is the reset path for the rest of your life. Unique password, app-based or hardware two-factor, recovery options cleaned up.
Use a password manager and stop reusing passwords. Credential stuffing — attackers trying breached passwords across other sites — is the single most common way ordinary accounts fall, and unique passwords defeat it entirely.
Turn on two-factor for email, banking, payments, and your primary social accounts. Prefer an authenticator app or hardware key over SMS.
Keep devices and browsers updated. Automated attacks rely overwhelmingly on known vulnerabilities that were patched months ago.
Back up what is irreplaceable, with at least one copy that is not connected to your computer. This is your defence against ransomware, theft, and hardware failure simultaneously.
Slow down on messages that create urgency. Almost every successful scam depends on the target acting fast. A five-minute pause and an independent verification call defeats most of them. Notice what is not on that list: VPNs for everyday browsing, antivirus beyond what the operating system already provides, webcam covers, and elaborate encryption workflows. Those are not useless — they are simply not top-six for most threat models, and putting them first is how people spend their limited attention in the wrong place. https://github.com/tarunjaswani/CORS-Misconfiguration/tree/main https://github.com/tarunjaswani/CSV-Injection/tree/main When Your Model Should Change. • You take a role with access to money, systems, or sensitive client data. Your professional access is now a target independent of your personal life. • You become publicly visible — journalism, activism, a public commercial profile. Targeted attention becomes plausible where it previously was not. • You start holding assets that are irreversible when stolen, such as significant cryptocurrency. Irreversibility raises the consequence side of every calculation. • A relationship ends badly, or someone with prior physical access to your devices becomes hostile. The people-who-know-you threat moves sharply up the list. https://github.com/tarunjaswani/ai-job-search Security is not a list of instructions, it is a set of decisions about a specific life. What do I have, who would want it, how bad is it if they get it, and what will I actually keep doing. One hour with those four questions produces a personal priority order worth more than any list of a hundred tips — because it tells you what to do first, and what you can safely stop worrying about. — Tarun Jaswani https://www.facebook.com/people/TarunJaswani/61588987721538/ https://github.com/tarunjaswani

TAGS

Cybersecurity #ThreatModel #TarunJaswani #InfoSec #Privacy #OnlineSafety #RiskManagement #DigitalSafety #Security #Awareness

Attackers Do Not Break Your Password Anymore. They Take Over Your Account Recovery.

Tarun Jaswani — Fri, 07 Aug 2026 11:24:29 +0000

You picked a long password, turned on two-factor, and felt secure. Meanwhile the actual attack path runs around all of it — through your recovery email, your phone number, your security questions, and a support agent who believes a convincing story. This is how accounts really get taken, and how to close the door.
Security Researcher • Penetration Tester
Tarun Jaswani writes about technology and security for everyday people — the practical habits that keep ordinary lives safe online, explained without jargon and always from the side of the person trying to protect themselves.

Almost nobody's account gets taken by someone guessing their password. That is the movie version. The real version is quieter and far more effective: the attacker never touches your password at all. They go to the "forgot password" flow and work on the thing that sits behind it — your recovery email, your phone number, your security questions, or a support agent who can be talked into a reset. Every one of those is a door into the same house, and most people have spent years hardening the front door while leaving the others unlocked.
https://about.me/tarun_jaswani
This matters because your account security is not the strength of your password. It is the strength of the weakest path that leads to a password reset. If your bank login is protected by a twenty-character passphrase but the reset link goes to an old email address you have not opened since 2019, your bank login is protected by that old email address.
https://medium.com/@rajkarar814/how-cybersecurity-can-change-the-world-dd4cd368c346
The Recovery Chain — Draw It Before an Attacker Does.
Every important account has a chain behind it. Your bank sends resets to your primary email. Your primary email sends resets to a recovery email and a phone number. That recovery email may itself have a recovery option pointing somewhere else. Follow that chain far enough and you almost always arrive at one or two accounts that everything else depends on.
Those one or two accounts are your real crown jewels, and most people have never identified them. Take twenty minutes and actually map it: for each important account, write down where a password reset would be sent. Then do the same for those destinations. The account that appears most often at the end of the chains is the one that deserves the strongest protection you are capable of applying.
The single sentence version
Your account is only as secure as the weakest account that can reset it. Harden the recovery chain, not just the login.
Attack Path One: The Abandoned Recovery Email.
Old email addresses are a common weak point. A provider may reclaim a long-dormant address, an old work or college address gets deprovisioned, or the account simply sits unused with a password from a decade ago that has since appeared in a breach dump. If any of those addresses is still listed as a recovery option on a current account, it is a live path in.
Go through the recovery settings of your important accounts and remove every address you no longer actively control and monitor. Replace them with one you check regularly and have secured properly. An unmonitored recovery address is worse than none, because it lets a reset happen without you ever seeing the notification.
https://www.linkedin.com/in/tarun-jaswani-a85b55401/
Attack Path Two: Your Phone Number.
SMS-based recovery is convenient and structurally weak. A SIM swap — where an attacker persuades or bribes a mobile operator into porting your number onto their SIM — hands them every code sent to that number. It is not exotic; it is a known and repeatedly documented technique, and it is particularly damaging because the phone number often sits behind email, banking, and payment apps simultaneously.
• Move away from SMS codes wherever the service offers an authenticator app or a hardware security key. App-based codes are generated on your device and are not intercepted by taking over your number.
• Ask your mobile operator what protections they offer against unauthorised porting — many support a port-out PIN, a lock, or an in-person verification requirement. Enable whatever exists.
• Remove your phone number as a recovery option on accounts where you have a stronger method available. Keeping it "just in case" preserves the weak path you were trying to eliminate.
• Treat sudden loss of mobile signal as a possible signal, not just an outage. If your phone loses service unexpectedly and stays down, check with your operator rather than waiting it out.
https://x.com/TJaswani7857
Attack Path Three: Security Questions Are Public Records.
Mother's maiden name. First school. City you were born in. Name of your first pet. These were designed in an era before people posted their lives publicly. Today, most security question answers are discoverable from social media, public records, or a friendly conversation.
The fix is simple and slightly counterintuitive: do not answer security questions truthfully. Treat each one as a second password. Generate a random string, store it in your password manager alongside the login, and use that as the answer. There is no rule requiring your first school to be a real school. An attacker who researches your life perfectly still cannot guess a random string.
Attack Path Four: The Support Agent.
The hardest path to defend is the human one. An attacker calls or messages support, presents a plausible story and a handful of personal details gathered from breaches and social media, and asks for help getting back into "their" account. Support exists to help people who are genuinely locked out, which is exactly the sympathy an attacker exploits.
You cannot control the provider's training, but you can reduce your exposure. Enable any advanced protection programme the provider offers — several major platforms have one, and they typically restrict what support can do without a hardware key. Reduce the personal details that are publicly discoverable about you. And where a provider allows you to set a support PIN or passphrase required for account changes, set it.
https://github.com/tarunjaswani
What to Actually Do This Week.

Map the recovery chain for your primary email, your bank, and your main payment app. Identify the one account everything ultimately depends on.
Secure that account with the strongest method available: a hardware security key if supported, an authenticator app if not, plus a unique password stored in a password manager.
Remove every stale recovery email and every unnecessary recovery phone number from your important accounts.
Replace SMS codes with app-based or hardware-based codes anywhere the option exists.
Overwrite all security question answers with random strings saved in your password manager.
Turn on login and recovery alerts so an attempted reset generates a notification you will actually see.
Enrol in the provider's advanced protection programme if one exists for your most critical account. https://github.com/tarunjaswani/agent-scripts A strong password protects the front door. Account recovery is the side gate, the back door, and the spare key under the mat, and it is where accounts are actually lost. Map the chain, find the account everything depends on, and protect that one as if everything depends on it — because it does. — Tarun Jaswani https://www.facebook.com/people/TarunJaswani/61588987721538/

TAGS

Cybersecurity #AccountSecurity #TarunJaswani #2FA #SIMSwap #Phishing #OnlineSafety #InfoSec #Privacy #DigitalSafety

Secure Coding Starts Before the First Line of Code

Tarun Jaswani — Sat, 01 Aug 2026 12:45:21 +0000

Introduction

Many security vulnerabilities aren't introduced by advanced attackers—they're unintentionally created during software development. Secure coding is not about fixing bugs after deployment; it's about preventing vulnerabilities from being introduced in the first place.

Security should be integrated into every stage of the software development lifecycle.

Common Software Vulnerabilities

Several classes of vulnerabilities appear repeatedly across applications:

SQL Injection
Cross-Site Scripting (XSS)
Cross-Site Request Forgery (CSRF)
Broken Access Control
Server-Side Request Forgery (SSRF)
Insecure Deserialization
Command Injection
Path Traversal

Most of these stem from insufficient input validation, improper authorization, or unsafe handling of user data.

Validate Every Input

Never assume incoming data is trustworthy.

User input should always be:

Validated
Sanitized where appropriate
Restricted using allowlists
Checked for expected formats and lengths

Input validation significantly reduces the likelihood of injection attacks.

Principle of Least Privilege

Applications should operate with only the permissions they truly require.

Examples include:

Database accounts with minimal privileges
Restricted filesystem access
Limited API permissions
Isolated service accounts

Reducing privileges minimizes the impact if an application is compromised.

Secure Authentication

Strong authentication involves more than simply verifying usernames and passwords.

Modern applications should support:

Multi-factor authentication
Secure password hashing
Rate limiting
Account lockout policies
Secure session management
Token expiration and rotation

Proper authentication protects both users and critical business data.

Dependency Management

Modern software relies heavily on third-party libraries.

Developers should:

Regularly update dependencies
Remove unused packages
Monitor security advisories
Perform Software Composition Analysis (SCA)

Outdated libraries frequently become attack vectors.

Logging and Monitoring

Security incidents often go unnoticed because applications fail to generate meaningful logs.

Important events to log include:

Authentication attempts
Privilege changes
Administrative actions
API failures
Unexpected exceptions
Security policy violations

Logs should be centralized, protected from tampering, and continuously monitored.

Security Testing Throughout Development

Security testing should be continuous rather than a final deployment step.

Effective practices include:

Static Application Security Testing (SAST)
Dynamic Application Security Testing (DAST)
Dependency scanning
Secret detection
Code reviews
Penetration testing

Automated scanning combined with manual review provides broader coverage.

Foster a Security-First Culture

Secure coding is not solely the responsibility of security teams.

Developers, testers, architects, and operations teams should collaborate throughout the development lifecycle. Organizations that embrace DevSecOps integrate security into development workflows without slowing innovation.

Conclusion

Secure software doesn't happen by accident. It results from thoughtful design, disciplined development practices, continuous testing, and ongoing education. By incorporating security from the beginning, organizations reduce technical debt, lower remediation costs, and build applications that users can trust.

Reference:
https://x.com/TJaswani7857

Why Identity Is the New Security Perimeter

Tarun Jaswani — Sat, 01 Aug 2026 12:27:50 +0000

Introduction

For years, organizations built their security strategies around protecting the network perimeter. Firewalls, VPNs, and intrusion prevention systems formed the first line of defense. However, as cloud computing, remote work, and Software-as-a-Service (SaaS) platforms became the norm, the traditional perimeter largely disappeared. Today, identity has become the primary target for attackers—and the primary control point for defenders.

Why Attackers Target Identity

Instead of exploiting sophisticated vulnerabilities, many attackers now focus on stealing credentials or hijacking authenticated sessions. Once inside a trusted account, they often blend in with legitimate users, making detection much more difficult.

Common techniques include:

Phishing attacks
Credential stuffing
Password spraying
Session token theft
MFA fatigue attacks
OAuth abuse

A compromised identity often grants attackers immediate access to sensitive resources without needing to exploit additional vulnerabilities.

Zero Trust Begins with Identity

The Zero Trust model operates on a simple principle:

Never trust. Always verify.

Rather than assuming users inside a network are trustworthy, every request is continuously evaluated based on multiple signals:

User identity
Device health
Location
Time of access
Risk score
Behavioral patterns

This approach significantly reduces the impact of stolen credentials.

Building Strong Identity Security

Organizations should adopt several best practices:

Implement Multi-Factor Authentication (MFA)

While MFA isn't foolproof, it remains one of the most effective defenses against credential theft.

Use Strong Identity Providers

Centralized authentication through trusted identity providers improves visibility and simplifies access management.

Apply Least Privilege

Users should only have access to resources necessary for their responsibilities. Excessive permissions dramatically increase the damage a compromised account can cause.

Monitor Authentication Logs

Authentication events often reveal the earliest indicators of compromise.

Watch for:

Impossible travel
Multiple failed logins
Unusual login times
New device registrations
Sudden privilege escalation
Passwords Alone Are No Longer Enough

Passwords continue to be reused across services, exposed in data breaches, and targeted through phishing campaigns. Modern organizations are increasingly adopting passwordless authentication using:

Passkeys
Hardware security keys
Biometric authentication
FIDO2 standards

These technologies reduce phishing risks while improving user experience.

The Human Factor

Technology alone cannot prevent identity attacks.

Regular security awareness training should teach users how to recognize:

Fake login pages
MFA push fatigue
Business email compromise
Social engineering attempts

Creating a security-conscious culture is just as important as deploying new tools.

Conclusion

Identity has become the new perimeter. Organizations that invest in strong authentication, continuous verification, least privilege, and proactive monitoring will be significantly better prepared for today's evolving threat landscape. As attackers increasingly target users rather than infrastructure, protecting digital identities is no longer optional—it's fundamental to modern cybersecurity.

For Reference:
https://x.com/TJaswani7857
https://github.com/tarunjaswani

Lessons Every Cybersecurity Engineer Learns from Real-World Web Applications

Tarun Jaswani — Fri, 31 Jul 2026 10:46:49 +0000

Every web application tells a story.

Some demonstrate excellent engineering.

Others unintentionally expose valuable lessons through their vulnerabilities.

Working with modern web applications reinforces one important truth: security is rarely broken by a single catastrophic mistake. More often, multiple small weaknesses combine to create significant risk.

Small Issues Become Big Problems

Consider a simple sequence:

A user uploads a file.

The application performs limited validation.

An administrator later views that file.

The browser executes unexpected content.

A seemingly harmless upload feature becomes a security issue because several assumptions failed.

Modern attacks often chain multiple weaknesses together.

Configuration Is Just as Important as Code

Applications frequently inherit risk from their environments.

Examples include:

Debug mode enabled in production
Public cloud storage buckets
Default credentials
Misconfigured CORS policies
Missing HTTP security headers
Exposed administrative interfaces

Secure deployments require attention beyond application code.

Dependencies Deserve Regular Attention

Most modern applications depend on hundreds of open-source packages.

These libraries accelerate development but also introduce supply-chain risk.

Good dependency management includes:

Regular updates
Vulnerability monitoring
Version pinning
Reviewing unnecessary packages
Removing abandoned libraries

A secure application depends on a secure ecosystem.

Human Factors Remain Critical

Technology alone cannot eliminate security incidents.

Phishing attacks, weak passwords, accidental data exposure, and social engineering continue to succeed because people remain an essential part of every system.

Security awareness complements technical defenses.

Defense in Depth

No single control provides complete protection.

Effective security layers include:

Authentication
Authorization
Encryption
Input validation
Monitoring
Logging
Rate limiting
Web Application Firewalls
Secure backups
Incident response planning

When one layer fails, others continue protecting the system.

Security Is an Ongoing Journey

There is no perfectly secure application.

New vulnerabilities emerge.

Frameworks evolve.

Browsers change.

Attack techniques improve.

Organizations that embrace continuous improvement respond more effectively than those seeking one-time perfection.

Final Thoughts

Web2 security continues to influence nearly every digital service people use daily.

Strong engineering practices, continuous learning, and proactive security thinking remain the foundation of resilient software.

Cybersecurity is not simply about finding vulnerabilities—it is about understanding systems, reducing risk, and helping build technology that users can trust with confidence.

Reference and Connect:
https://www.linkedin.com/in/tarun-jaswani-a85b55401/
https://x.com/TJaswani7857
https://www.facebook.com/people/TarunJaswani/61588987721538/

https://about.me/tarun_jaswani
https://github.com/tarunjaswani
https://hashnode.com/@tarunjaswani121

Secure Coding Is More Than Fixing Vulnerabilities

Tarun Jaswani — Fri, 31 Jul 2026 10:45:27 +0000

Secure Coding Is More Than Fixing Vulnerabilities

Many developers think security begins after coding ends.

In reality, security begins with the first design decision.

Secure coding is not about adding defensive checks after an application is finished. It is about building software that naturally resists attacks throughout its lifecycle.

Think Like an Attacker

One of the most valuable habits any developer can build is asking:

What assumptions am I making?
Can this input be manipulated?
What happens if authentication fails?
Can users access data they shouldn't?
What if this API is abused?

Thinking from an attacker's perspective often reveals weaknesses before they become production incidents.

Input Validation Matters

Nearly every application accepts user input.

Search boxes.

Comments.

Profile updates.

File uploads.

APIs.

Every input represents an opportunity for attackers to manipulate application behavior.

Never trust user-controlled data.

Validate it.

Sanitize it.

Encode it when necessary.

The Principle of Least Privilege

Applications should grant only the permissions required for each operation.

Examples include:

Users should access only their own resources.
Administrators should perform privileged operations only when necessary.
Services should use minimally privileged accounts.
Databases should restrict unnecessary permissions.

Reducing privileges reduces risk.

Logging Is a Security Feature

Good logging helps organizations:

Detect attacks
Investigate incidents
Understand abnormal behavior
Improve defensive capabilities

However, logs should never expose:

Passwords
Authentication tokens
Credit card information
API secrets
Personally identifiable information

Useful logging balances visibility with privacy.

Security Reviews Improve Quality

Code reviews should evaluate more than functionality.

Security reviews examine:

Input validation
Authorization
Authentication
Error handling
Secret management
Dependency usage

Security-focused reviews often improve overall software quality.

Continuous Learning

Threats evolve every year.

Developers should regularly study:

OWASP Top 10
Secure design principles
Common attack techniques
Modern authentication methods
Cloud security practices

Learning security is an ongoing process rather than a one-time milestone.

Conclusion

Secure coding is not the responsibility of security teams alone.

Every developer influences the security posture of an application.

Writing secure code today prevents incidents tomorrow, protects users, and strengthens trust in the software we build.

Reference and Connect:
https://www.linkedin.com/in/tarun-jaswani-a85b55401/
https://x.com/TJaswani7857
https://www.facebook.com/people/TarunJaswani/61588987721538/

https://about.me/tarun_jaswani
https://github.com/tarunjaswani
https://hashnode.com/@tarunjaswani121

Why Web2 Security Still Matters in an AI-Driven World

Tarun Jaswani — Fri, 31 Jul 2026 10:44:20 +0000

Artificial intelligence, blockchain, and Web3 have captured much of the technology spotlight in recent years. Yet behind almost every modern application lies a Web2 infrastructure that continues to power authentication systems, APIs, cloud platforms, enterprise software, and millions of websites.

While new technologies evolve rapidly, attackers continue to exploit the same Web2 weaknesses that have existed for years. Organizations lose millions of dollars annually because of vulnerabilities such as SQL injection, cross-site scripting (XSS), insecure authentication, exposed cloud storage, and broken access controls.

The reality is simple: Web2 remains the foundation of the internet.

The Growing Attack Surface

Modern applications are no longer monolithic. A single platform may include:

Frontend applications
Backend APIs
Mobile applications
Cloud infrastructure
Third-party integrations
Payment gateways
Authentication providers
CDN services
CI/CD pipelines

Every additional component introduces another potential attack vector.

Security is no longer about protecting a single web server. It is about securing an entire ecosystem.

Authentication Is Still the Weakest Link

Many successful attacks begin with compromised credentials rather than sophisticated exploits.

Common authentication weaknesses include:

Weak passwords
Password reuse
Missing MFA
Session fixation
Session hijacking
Poor JWT implementation
Broken password reset flows

A secure authentication system must balance usability with strong protection.

APIs Have Become Prime Targets

Modern applications rely heavily on REST and GraphQL APIs.

Unfortunately, many organizations expose APIs that suffer from:

Broken Object Level Authorization (BOLA)
Excessive data exposure
Missing rate limiting
Improper input validation
Weak authorization logic

API security deserves the same attention as frontend security.

Security Must Be Continuous

Many organizations perform security assessments only before deployment.

That approach is outdated.

Continuous security includes:

Static analysis
Dynamic testing
Dependency scanning
Infrastructure monitoring
Log analysis
Vulnerability management
Regular penetration testing

Security should evolve alongside the application.

Security Is Everyone's Responsibility

Developers, DevOps engineers, product managers, QA teams, and security professionals all contribute to secure software.

The earlier security becomes part of development, the lower the cost of fixing vulnerabilities.

Final Thoughts

Web2 is not disappearing anytime soon.

Banks, healthcare providers, governments, SaaS companies, e-commerce platforms, and social media services continue to depend on Web2 technologies every day.

Building secure Web2 applications remains one of the most valuable engineering skills. Organizations that invest in secure coding, continuous testing, and proactive security practices will be far better prepared for the evolving threat landscape.

Reference and Connect:
https://www.linkedin.com/in/tarun-jaswani-a85b55401/
https://x.com/TJaswani7857
https://www.facebook.com/people/TarunJaswani/61588987721538/

https://about.me/tarun_jaswani
https://github.com/tarunjaswani
https://hashnode.com/@tarunjaswani121

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