React JS security guide: vulnerabilities, risks and fixes

In a widely reported supply chain attack, the chalk, debug, and 16 other npm packages with a combined 2.6 billion weekly downloads were compromised simultaneously. The attack did not target a React JS flaw. It targeted how React JS applications consume open-source dependencies without scrutinising what those dependencies contain.

That is the uncomfortable truth about React JS security: the library itself is not the problem. The way teams configure, extend, and integrate React applications is. Synopsys reported that 96% of commercial codebases contain open-source components, and 84% of those contain at least one known vulnerability. React JS development sits inside that statistic. React applications power over 13% of the top 1 million websites globally, which makes the React ecosystem one of the most actively targeted surfaces in frontend software today.

This guide covers the most critical React security vulnerabilities, the specific conditions that trigger them, and the steps that eliminate them. This is not a primer on React features; it is a practical security reference for teams building React applications that handle real user data.

Key takeaways

• Most React security vulnerabilities are not React’s fault; they result from misuse of its APIs, insecure dependency management, and configuration errors that expose attack surfaces React’s defaults cannot cover.
• Cross-site scripting (XSS) remains the highest-priority threat in React JS applications, particularly when dangerouslySetInnerHTML or unsanitised URL inputs are involved.
• A single supply chain attack can hit npm packages with billions of weekly downloads combined, underscoring how dependency risk is now a primary React JS security concern.
• Storing authentication tokens in localStorage is one of the most common and most consequential security mistakes in React js web development.
• React JS application development teams can address the majority of these vulnerabilities through systematic practices: input sanitisation, secure token storage, routine dependency auditing, and content security policy (CSP) implementation.
• React JS security is a shared responsibility across the entire delivery stack: the frontend, the API layer, the infrastructure, and the dependency chain.

Is React JS secure?

React JS is not inherently insecure, but it is also not inherently secure. It is a tool, and like most tools, its safety depends almost entirely on how it is used.

Out of the box, React JS provides a meaningful default protection: JSX auto-escaping. Any content rendered inside a JSX expression is automatically treated as a string and escaped before it reaches the DOM. That single default prevents a large category of direct injection attacks. However, this protection applies only to JSX-rendered content and does not extend to dangerouslySetInnerHTML, user-controlled URLs, serialised server-side state, or third-party scripts loaded into the page.

The honest answer is: React JS is as secure as the decisions your team makes around it. The framework does not manage authentication, does not enforce HTTPS, does not validate API inputs, and does not audit its own dependencies. These are responsibilities that fall on the team building the React JS application, not on the library itself.

React’s built-in protections

React JS ships with several default security behaviours that reduce the attack surface compared to raw DOM manipulation. Understanding what they do and where they stop is the starting point for building secure React applications.

JSX auto-escaping. When you render user input inside a JSX expression ({userInput}), React converts any HTML characters to their escaped equivalents before inserting them into the DOM. A string containing <script>alert(1)</script>becomes harmless text on screen rather than executable code. This eliminates a large class of reflected XSS attacks for content rendered through standard JSX.

Protection against direct HTML injection. React’s rendering pipeline is deliberately designed to treat all JSX-rendered values as data, not markup. You cannot accidentally render raw HTML by passing a string through a JSX expression; you have to explicitly opt out of this protection using dangerouslySetInnerHTML.

URL sanitisation from React 16.9 onwards. React introduced automatic blocking of javascript: URLs in href and srcattributes when they are rendered through JSX. Attempts to render a javascript: link via JSX produce a warning and a blocked link rather than an executable payload.

Server Component isolation. React Server Components do not expose their source code, server-side environment variables, or internal logic to the client by default. Sensitive computation stays on the server, and only the rendered output is sent to the browser.

These protections are real and meaningful. They are also limited to what React controls: the rendering layer. The moment data leaves the React rendering pipeline (into a database, a third-party API, an authentication system, or an npm dependency), React’s protections no longer apply.

React vs application security

One of the most common misunderstandings in React js web development is treating React JS security as synonymous with application security. They are not the same thing.

React JS is responsible for a narrow slice of a web application: the rendering of the user interface. It controls how data is displayed in the browser and provides tools for managing component state. That is the extent of its scope. Application security covers a much broader surface: how data is stored, how users are authenticated, how API requests are validated, how dependencies are managed, how secrets are protected, and how the infrastructure the application runs on is hardened.

The practical implication is that securing your React JS application is necessary but not sufficient for securing your application. A React application with perfect JSX escaping can still expose user data through an API that does not validate its inputs. A React application with secure token storage can still be compromised through a malicious npm dependency. A React application with a strict content security policy can still be breached if the server it communicates with stores passwords in plain text.

React JS security and application security are complementary disciplines. This guide covers both: the React-specific attack surfaces and the application-layer decisions that React JS teams are responsible for, even when they sit outside the React rendering layer.

Why React application security matters

React application security matters for 2 reasons that reinforce each other: scale and integration.

On scale: Stack Overflow’s Developer Survey found that React is used by 46.9% of professional developers, making it the most widely deployed JavaScript library on the web. At that scale, a single exploitable pattern in React js application development can affect tens of thousands of deployed applications simultaneously. Attackers do not find a vulnerability in one React app; they find a pattern that applies across many. The value of targeting a React-specific attack vector is proportional to React’s adoption, and that adoption is at an all-time high.

On integration: React JS applications do not exist in isolation. They communicate with APIs, consume third-party services, install npm packages, and store data in backends that React itself does not control. Each integration point is a potential attack surface. The open-source nature of React libraries means that any dependency in the supply chain is a potential injection point, not just your own code. React JS features like dangerouslySetInnerHTML and server-side rendering with unsanitised data introduce attack surfaces that React’s defaults cannot cover. And the pace of React js web development often prioritises delivery speed over security review.

The result is a vulnerability profile that is well-understood, consistently exploited, and largely preventable.

React security vulnerabilities at a glance

The table below summarises the most common React security vulnerabilities, the attack vector, what React’s default protections cover, and what additional action is required.

React JS security vulnerabilities: the complete breakdown

1. Cross-site scripting (XSS)

Cross-site scripting is the single most exploited vulnerability class in React applications. It occurs when untrusted input is rendered as executable code in the browser. React’s JSX auto-escaping provides a baseline defence: content rendered inside JSX expressions is escaped by default, meaning <script> tags and similar payloads are treated as strings, not code. But this protection applies only to JSX-rendered content.

Two patterns break that protection completely:

1. The first is dangerously Set Inner HTML. This React JS feature bypasses JSX escaping and injects raw HTML directly into the DOM. It exists for legitimate purposes (rendering pre-processed rich text, for example), but when it receives unsanitised user input or third-party content, it becomes an open injection sink. CVE-2025-59057 demonstrated this pattern at the framework level: React Router’s Meta API introduced an XSS vulnerability through server-side rendering of script:ld+jsontags, affecting all React Router installations below version 7.9.0.
2. The second pattern is user-controlled URLs. React applications that render href or src attributes from user input without validation allow javascript: scheme attacks, where clicking a rendered link executes arbitrary JavaScript in the user’s browser.

How to fix it: Sanitise all HTML that passes through dangerouslySetInnerHTML using DOMPurify before rendering. Validate all URL inputs against a whitelist of accepted schemes (http: and https: only). Implement a content security policy (CSP) header that restricts which scripts the page can execute. Keep React Router and all React libraries updated; the react.dev security advisory on React Server Components confirms that framework-level XSS patches are released regularly and staying current is not optional.

2. Insecure token storage

Authentication token storage is one of the most consequential decisions in React js web development, and it is one of the most commonly made incorrectly. Storing JSON Web Tokens (JWTs) or session tokens in localStorage or sessionStorageexposes them to any JavaScript running on the page. In React JS applications, that means a single XSS vulnerability anywhere on the page can escalate into a full credential theft incident.

The attack chain is straightforward: the attacker injects a script (via any of the XSS patterns above), the script reads localStorage, and the token is exfiltrated. The attacker then uses that token to impersonate the user against your API. localStorage provides no protection against this because any JavaScript running in the browser context can access it.

How to fix it: Store authentication tokens in server-set httpOnly cookies with the Secure and SameSite=Strict attributes applied. httpOnly cookies are inaccessible to JavaScript, which means that even a successful XSS injection cannot exfiltrate them. This single change removes token theft from the attack surface entirely. If your React JS application development team has architectural reasons to use localStorage (offline-first applications, for example), apply defence-in-depth: implement CSP, maintain a rigorous XSS-free codebase, and limit token lifetimes aggressively.

3. Dependency supply chain attacks

React JS applications typically depend on hundreds of npm packages. The npm registry has surpassed 2.5 million packages, and the attack surface represented by that dependency graph is enormous. A widely reported supply chain attack on chalk, debug, and 16 other packages demonstrated that even widely trusted, actively maintained packages can be compromised. An attacker who poisons a package that your React application installs has effectively compromised your application before you write a line of your own code.

This is not theoretical risk. Synopsys found that 84% of codebases with open-source components contain at least one known vulnerability in those components. In React JS development, where libraries like react-router, axios, lodash, and date-fns are standard dependencies, the probability of a transitive vulnerability in any given project is high.

How to fix it: Run npm audit routinely and before every production release. Add Socket’s CLI wrapper (alias npm=”socket npm”) for real-time malware detection during local development. Use Snyk or Dependabot for automated pull requests when new vulnerability disclosures affect your dependency tree. Review package-lock.json changes carefully during code review, particularly for minor and patch version updates. Pin critical dependencies to specific versions and review changes to those versions explicitly.

4. SQL and NoSQL injection

SQL injection affects React JS applications indirectly, through the API layer that React applications communicate with. When a React application sends unsanitised user input to an API that constructs database queries dynamically, the attacker can alter those queries to read, modify, or delete data they are not authorised to access. The React layer is not where the injection occurs, but React JS application development teams are responsible for ensuring that inputs from the frontend cannot serve as injection payloads.

NoSQL injection, targeting databases such as MongoDB, operates on the same principle with different syntax. In React js web development, this is particularly relevant when search forms, filter inputs, or query parameters are passed through to a MongoDB query without sanitisation.

How to fix it: Validate and sanitise all user input on the server side before it touches any database query. Use parameterised queries or an ORM (object-relational mapping) layer that prevents raw string interpolation in SQL contexts. Apply JSON schema validation to all API endpoints that accept user-controlled data from React applications. Audit every API call that a React application can initiate and verify that each one validates its input shape at the API layer, not just at the React form level.

5. Server-side rendering (SSR) attacks

React JS features include server-side rendering, which improves performance and SEO but introduces a specific class of vulnerability that does not exist in purely client-rendered React applications. The attack targets the serialisation of server-side data into the initial HTML payload. When server-state (for example, user data, session context, or API responses) is serialised using JSON.stringify() and embedded in a <script> tag before being sent to the browser, an attacker who can influence that data can inject executable JavaScript into the page before it even loads.

The CVE-2025-55183 disclosure (CVSS 5.3) on React Server Components involved source code exposure via improper handling of server-side responses. This class of vulnerability is specific to React JS application development that uses SSR or React Server Components and is not mitigated by client-side security practices alone.

How to fix it: Use the serialize-javascript npm package instead of JSON.stringify() when embedding server-side data in script tags. Validate all data that will be serialised server-side and strip any fields that should not be transmitted to the client. Do not embed sensitive server-side data (database credentials, internal API keys, PHI fields) in the initial HTML payload. Keep React and React Server Components updated to receive patches for known SSR-related disclosures.

6. Dangerous URL schemes

React applications that render URLs from user input or from unsanitised third-party data are vulnerable to javascript:scheme injection. When a user clicks a link rendered with a javascript: URL, the browser executes the URL content as JavaScript. React JS does not filter URL schemes by default before version 16.9, and even in later versions, the protection applies only to specific rendering contexts.

This vulnerability affects React applications that accept user-submitted links (social profiles, bio fields, import-from-URL features), render URLs from third-party data sources, or construct href or src attributes dynamically without validation.

How to fix it: Validate all URL values against an explicit scheme whitelist (accept only http: and https:) before rendering them in href or src attributes. Use the sanitize-url npm package for a drop-in validation function that rejects dangerous schemes. Never render user-provided URLs in an anchor tag without this validation step. Apply the same validation to URL values received from APIs or third-party data sources; treat external data with the same caution as direct user input.

7. Broken authentication and session management

React JS application development often separates the frontend session management from the backend authentication implementation. In that separation, gaps appear. React applications that handle session expiry on the client side without server-side validation allow attackers to extend sessions beyond their intended lifetime. Applications that do not invalidate tokens on the server after logout leave a window during which a stolen token remains valid. Applications that use weak or predictable session identifiers are vulnerable to session fixation attacks.

How to fix it: Implement server-side session validation for every authenticated request. Do not rely on React application state or localStorage session flags as the authority on whether a session is valid. Set aggressive token expiry (15 to 30 minutes for access tokens) and implement refresh token rotation. On logout, invalidate the session on the server, not just in the React application’s state. Apply rate-limiting to authentication endpoints to mitigate brute-force attacks against login flows in React js web development.

8. Arbitrary code execution and Zip Slip

Arbitrary code execution vulnerabilities occur when React JS application development includes the processing of archive files (ZIP, TAR) without validation of the extracted file paths. The Zip Slip vulnerability, documented across multiple React libraries that handle file uploads, allows an attacker to craft a malicious archive that extracts files outside the intended directory. If the extracted file is a script, configuration file, or executable, the attacker gains code execution capability on the server or client environment.

How to fix it: Validate all extracted file paths against the intended target directory before writing. Reject any path that traverses above the target directory (paths containing ../). Use updated, patched versions of archive-processing libraries and run npm audit before adding any library that handles file extraction to your React JS application. Run Zip Slip-specific security scans as part of your CI/CD pipeline for applications that process user-uploaded archives.

9. Lack of end-to-end encryption

React applications that transmit sensitive data over unencrypted channels or through API layers that do not enforce TLS (Transport Layer Security) expose that data to interception. Third-party APIs that React JS applications integrate with are a particular risk: if those APIs do not enforce HTTPS, data sent to them is transmitted in plain text. React libraries that make direct API calls from the client also expose API keys in the browser’s network tab if those keys are embedded in the application bundle.

How to fix it: Enforce HTTPS for all connections made by React applications, both to your own API and to any third-party services. Never embed API keys, secrets, or credentials directly in React JS application code; use environment variables that are injected at build time for public-facing keys and proxy sensitive API calls through your own backend where keys must remain private. Use crypto-js or the Web Crypto API for client-side encryption where sensitive data must be processed in the browser before transmission.

React security best practices

Applying these practices consistently across React JS application development addresses the majority of common attack vectors before they reach production.

Common React security mistakes developers make

The majority of React security vulnerabilities in production applications trace back to a small set of recurring mistakes. These are not obscure edge cases; they are patterns that appear across codebases at every stage of maturity.

Using dangerouslySetInnerHTML without sanitisation. The name is a warning, but developers reach for it when rendering rich text, markdown output, or CMS content. Without DOMPurify or equivalent sanitisation applied to the input before rendering, this is an open XSS vector. Every instance of dangerouslySetInnerHTML in a React application should be treated as a security review item.

Storing authentication tokens in localStorage. This is the most consequential mistake in React js web development. It is also one of the most common, partly because browser storage is simpler to work with than httpOnly cookies during development. The risk is binary: a single XSS vulnerability anywhere on the page can steal every token stored there.

Not auditing npm dependencies. Installing a package does not mean auditing it. React JS development teams regularly install packages without reviewing their dependency trees, checking for known CVEs, or pinning to a verified version. In a codebase that installs hundreds of packages, unchecked transitive dependencies are a significant and underappreciated attack surface.

Trusting client-side validation only. React applications can implement sophisticated form validation, but client-side validation can always be bypassed by a motivated attacker sending requests directly to the API. Every validation that matters must be enforced on the server. React form validation improves the user experience; it does not secure the API.

Hardcoding secrets in the React application bundle. API keys, secret tokens, and service credentials embedded in a React JS application are visible to anyone who loads the page and inspects the JavaScript bundle. Environment variables injected at build time for public-facing keys, and backend proxying for any key that must remain private, are the only acceptable patterns.

Not implementing a Content Security Policy header. A CSP header tells the browser which scripts, styles, and resources it is permitted to load. Without one, any injected script (via XSS, a compromised dependency, or a third-party service) can execute without restriction. CSP is one of the most effective mitigations against XSS injection, and it is absent from the majority of React applications in production.

How to test a React application for security

Security testing for React applications spans 4 distinct layers, each requiring different tools and approaches.

Static analysis (before deployment). ESLint with the eslint-plugin-react and eslint-plugin-security rules sets catches dangerous patterns in your codebase before any code runs: use of dangerouslySetInnerHTML, unvalidated URL rendering, hardcoded secrets, and eval usage. Run static analysis as part of every pull request review.

Component testing with the React Testing Library. The React Testing Library encourages testing from the user’s perspective: querying elements by visible text, accessible role, and label rather than by internal component structure. Security-relevant component tests verify that injection payloads are rendered as escaped text (not as executed scripts), that protected routes redirect unauthenticated users correctly, and that form inputs reject or sanitise malformed input before submission.

Dependency scanning. Run npm audit before every production release. Integrate Snyk or Dependabot to receive automated alerts when a CVE is published against a package in your dependency tree. Use Socket’s CLI wrapper for real-time detection of suspicious package behaviour during local development.

Dynamic application security testing (DAST). Tools like OWASP ZAP and Burp Suite scan running React applications for vulnerabilities that static analysis cannot detect: misconfigured CORS policies, missing security headers, exposed API endpoints, and authentication bypass paths. Run DAST against a staging environment that mirrors production configuration.

Manual penetration testing. Automated tools do not catch every vulnerability class. Manual testing by a developer familiar with the OWASP Top 10 and with the specific business logic of your React application is necessary before major releases, particularly for applications handling sensitive data. Pay particular attention to authentication flows, file upload handling, and any feature that accepts user-provided URLs or HTML.

React security checklist

Use this checklist before every production release of a React JS application.

Rendering and XSS

• [ ] Every use of dangerouslySetInnerHTML sanitises input with DOMPurify
• [ ] All user-provided URLs are validated against an http:/https: whitelist before rendering
• [ ] No raw HTML is rendered from unsanitised API responses or third-party sources
• [ ] sanitize-url is applied to all URL values used in href or src attributes

Authentication and session management

• [ ] Authentication tokens are stored in httpOnly cookies (not localStorage or sessionStorage)
• [ ] Cookies are configured with Secure and SameSite=Strict attributes
• [ ] Access tokens expire within 15 to 30 minutes
• [ ] Refresh token rotation is implemented and tokens are invalidated on logout
• [ ] Session validation is enforced on the server for every authenticated request

Dependency and supply chain

• [ ] npm audit has been run and all high/critical vulnerabilities resolved or risk-accepted
• [ ] package-lock.json changes in the latest release have been reviewed
• [ ] Critical dependencies are pinned to specific, verified versions
• [ ] Snyk or Dependabot is configured for continuous monitoring

Configuration and infrastructure

• [ ] A Content-Security-Policy header is implemented and configured for the production domain
• [ ] HTTPS is enforced for all API connections, including third-party services
• [ ] No API keys, secrets, or credentials are present in the React JS application bundle
• [ ] Sensitive API calls are proxied through the backend rather than made directly from the client

Server-side rendering

• [ ] serialize-javascript is used instead of JSON.stringify() for embedding server-state
• [ ] No sensitive fields (credentials, PHI, internal keys) are included in the serialised server payload
• [ ] React Server Components are kept updated to the latest patched release

Testing

• [ ] ESLint security rules are passing with no suppressions on known issues
• [ ] Component tests via the React Testing Library cover authentication flows and protected routes
• [ ] DAST has been run against a staging environment that mirrors production
• [ ] npm audit output has been reviewed (not just run)

How Spark Eighteen helps build secure React applications

Security in React JS applications is easier to maintain when it is built into the delivery process, not treated as an audit step at the end. The distinction matters: a security review at the end of a build cycle finds vulnerabilities that are expensive to fix. Security as a delivery property means those vulnerabilities are not introduced in the first place.

At Spark Eighteen, this approach shaped the ClaritasRx engagement from the start. ClaritasRx is a HIPAA-compliant multi-tenant SaaS platform rebuilt from a legacy stack, handling protected health information (PHI) for pharmaceutical clients. The security requirements were not an audit checklist tacked on at launch; they were architectural constraints that determined how the application was designed.

Every API route required mandatory authorisation checks as a structural property, not a middleware afterthought. PHI access was logged with immutable audit trails. Client-level database isolation was enforced at the data layer, not at the application layer. The QA process included 110+ Playwright end-to-end (E2E) specifications traced to Jira tickets, specifically designed to catch regressions before any PHI-touching code reached production. The result was a platform that could be handed to a compliance audit with confidence, not one that needed to be hardened before one.

The lesson that applies to React JS security more broadly: the vulnerabilities that cause the most damage are the ones that were never tested for. Arbitrary code execution, SSR injection, and supply chain risks are not exotic threats; they are predictable failure modes that a systematic delivery process catches before they reach users. The difference between a React application that is secure and one that is not is rarely a single decision; it is a consistent set of engineering practices applied throughout the build.

Conclusion

React JS security is not about React’s capability. It is about the decisions made during React JS application development: where tokens are stored, what gets sanitised before rendering, which packages are installed and reviewed, and whether authentication is validated on the server or trusted on the client.

The vulnerability landscape for React applications has become more sophisticated. Framework-level CVEs in React Router and React Server Components, supply chain compromises at npm scale, and the growing sophistication of XSS injection techniques mean that a static security checklist applied once at launch is not sufficient. React JS security requires ongoing dependency management, consistent application of the patterns covered in this guide, and a QA process that includes security-specific test coverage.

The good news is that the patterns are well-established. Teams that apply them consistently in their React js web development process ship applications that are significantly harder to exploit, not because they are impenetrable, but because they eliminate the straightforward paths attackers rely on most.

If you are assessing the security posture of an existing React JS application or planning security-first architecture for a new build, write to us at coffee@sparkeighteen.com.