Securing CRA React Apps

Abstract representation of cybersecurity

Summary

Over the years, I’ve built and maintained several Create React App (CRA) projects before I discovered frameworks, and security has been a constant battle—especially in the early days when I was still learning. This guide is a reflection of my journey, highlighting the rookie mistakes I made, the vulnerabilities I discovered through painful trial and error, and the best practices I implemented to harden my apps. From exposing API keys in client-side code to falling victim to XSS attacks, I’ve seen it all, and I want to share these lessons to help others avoid the same pitfalls.

Context

Focus: Application security for modern JavaScript frontends, with a special emphasis on the vulnerabilities that creep into young, rapidly developed apps.
Target Audience: Developers like me who are building or maintaining React applications using Create React App, especially those transitioning from prototypes to production.
Goal: To share my real-world experiences and provide actionable fixes that I’ve tested and refined over multiple projects.

Architecture & Evolution

Core Technology: Create React App (CRA) as the scaffolding tool that got me started quickly, but which I later learned to customize for security.
Development Practices: I started with basic setups but evolved to incorporate secure coding principles after experiencing breaches and audits.
Evolution: My approach has matured through hands-on fixes, from manual dependency audits to automated security pipelines, adapting to emerging threats like supply chain attacks.

Common Pitfalls & Fixes

1. Exposed Environment Variables

Pitfall: Early on, I hardcoded API keys directly into my CRA code, thinking .env files with REACT_APP_ prefixes were secure. I realized too late that these get bundled into the client-side build, exposing secrets to anyone who inspects the source.

Fix: I switched to server-side proxying for sensitive operations. Instead of storing keys client-side, I created a backend API that handles authentication and data fetching. For non-sensitive config, I use .env files but never prefix sensitive vars with REACT_APP_. I also implemented runtime checks to ensure no secrets leak during builds.

2. Cross-Site Scripting (XSS) Vulnerabilities

Pitfall: In one project, I rendered user-generated content directly in JSX without sanitization, leading to a potential XSS attack when a user submitted malicious HTML. It was a wake-up call when I ran a security audit and found the vulnerability.

Fix: I integrated dompurify for all dynamic content. Now, I sanitize inputs before rendering: const cleanHTML = DOMPurify. sanitize(dangerousHTML);. I also adopted React’s built-in protections like using dangerouslySetInnerHTML sparingly and preferring controlled components for forms.

3. Insecure Dependencies

Pitfall: I once used an outdated version of a popular library that had a known vulnerability, discovered during a penetration test. It could have allowed code injection if exploited.

Fix: I run npm audit weekly and use tools like npm-check-updates to keep dependencies current. For critical updates, I test in staging environments first. I’ve also adopted Dependabot for automated PRs on vulnerable packages, reducing manual oversight.

4. Lack of HTTPS Enforcement

Pitfall: Deploying to a platform without HTTPS, I exposed user data in transit during a demo, which could have been intercepted.

Fix: I enforce HTTPS everywhere—using helmet middleware for security headers and configuring my deployment (e.g., on Vercel or Netlify) to redirect HTTP to HTTPS. I also use Strict-Transport-Security headers to prevent downgrade attacks.

5. Improper Error Handling

Pitfall: My early apps leaked stack traces in production errors, giving away internal app structure to potential attackers.

Fix: I implemented generic error boundaries in React and centralized error logging with services like Sentry. Client-side errors now show user-friendly messages, while detailed logs go to secure servers. I also added rate limiting to prevent error-based reconnaissance.

6. Client-Side Routing Vulnerabilities

Pitfall: Relying on client-side auth checks for protected routes, I discovered users could bypass them by manipulating the URL directly.

Fix: I moved all authorization to the server-side, using JWT tokens validated on each API call. Client-side routing now acts as a UX layer, with real security enforced backend.

Highlights

Detailed breakdowns of real pitfalls I’ve encountered, like the time I exposed API keys and had to scramble to rotate them.
Practical, tested fixes for preventing XSS that I’ve implemented across multiple projects.
Hands-on guidance on dependency management, including how I set up automated audits.
Best practices for environment variables and sensitive data, refined through my own security incidents.
Recommendations for CSP and security headers that I’ve deployed successfully, including custom policies tailored to CRA builds.

Impact

These fixes have dramatically improved the security posture of my React applications, preventing potential breaches.
I’ve eliminated risks from common vulnerabilities like XSS and data exposure in all my active projects.
This experience has instilled a security-first mindset in my development workflow, influencing how I approach new builds.

Lessons Learned

Reflecting on these experiences, the biggest takeaway is that security isn’t an afterthought—it’s baked into every decision. I learned to treat vulnerabilities as learning opportunities rather than failures, and now I proactively scan for issues during development. If I could tell my past self one thing, it’d be: “Audit early, audit often, and never trust client-side alone.” These lessons have not only secured my apps but also made me a more thoughtful developer overall.