Bolt security

Insecure Cookie Configuration in Bolt Application

Your Bolt.new application stores authentication tokens or session data in cookies without proper security attributes. Missing HttpOnly, Secure, and SameSite flags leave your users' sessions vulnerable to theft through XSS attacks, man-in-the-middle interception, and cross-site request forgery.

When Bolt generates authentication code, it may set cookies using basic document.cookie assignments or use a cookie library with default (insecure) settings. This means session tokens can be read by JavaScript (enabling XSS-based theft), transmitted over unencrypted HTTP connections, and sent along with cross-site requests.

An attacker who steals a session cookie can impersonate any user on your platform, access their data, make purchases on their behalf, or escalate privileges to admin accounts. This is a silent vulnerability that leaves no trace until it's exploited.

Error Messages You Might See

Warning: Cookie set without HttpOnly flag Cookie rejected due to SameSite=None without Secure Set-Cookie header ignored: must be Secure when SameSite=None Mixed Content: cookie will be blocked in future browser versions
Warning: Cookie set without HttpOnly flagCookie rejected due to SameSite=None without SecureSet-Cookie header ignored: must be Secure when SameSite=NoneMixed Content: cookie will be blocked in future browser versions

Common Causes

  • Missing HttpOnly flag — Cookies are readable by JavaScript via document.cookie, so any XSS vulnerability can steal session tokens
  • Missing Secure flag — Cookies are sent over unencrypted HTTP connections, allowing interception on public WiFi networks
  • SameSite not set to Strict or Lax — Cookies are sent with cross-site requests, enabling CSRF attacks
  • Cookies set from client-side JavaScript — Using document.cookie or js-cookie instead of setting cookies from the server with proper flags
  • Overly broad cookie domain or path — Cookies scoped to a parent domain or root path, making them accessible to other subdomains or paths that may be compromised

How to Fix It

  1. Set cookies from the server — Use Set-Cookie headers from your API routes instead of document.cookie: res.setHeader('Set-Cookie', `token=${value}; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400`)
  2. Enable HttpOnly — This prevents JavaScript from accessing the cookie, blocking XSS-based theft entirely
  3. Enable Secure flag — Ensures cookies are only sent over HTTPS connections, preventing interception
  4. Set SameSite to Lax or Strict — Lax allows cookies on top-level navigations (links), Strict blocks all cross-site cookie sending
  5. Use a session library — Install iron-session or next-auth which handle secure cookie configuration by default
  6. Set proper expiration — Use Max-Age or Expires instead of session cookies for persistent login, and set reasonable timeouts

Real developers can help you.

Matthew Butler Matthew Butler Systems Development Engineer @ Amazon Web Services Milan Surelia Milan Surelia Milan Surelia is a Mobile App Developer with 5+ years of experience crafting scalable, cross-platform apps at 7Span and Meticha. At 7Span, he engineers feature-rich Flutter apps with smooth performance and modern UI. As the Co-Founder of Meticha, he builds open-source tools and developer-focused products that solve real-world problems. Expertise: 💡 Developing cross-platform apps using Flutter, Dart, and Jetpack Compose for Android, iOS, and Web. 🖋️ Sharing insights through technical writing, blogging, and open-source contributions. 🤝 Collaborating closely with designers, PMs, and developers to build seamless mobile experiences. Notable Achievements: 🎯 Revamped the Vepaar app into Vepaar Store & CRM with a 2x performance boost and smoother UX. 🚀 Launched Compose101 — a Jetpack Compose starter kit to speed up Android development. 🌟 Open source contributions on Github & StackOverflow for Flutter & Dart 🎖️ Worked on improving app performance and user experience with smart solutions. Milan is always happy to connect, work on new ideas, and explore the latest in technology. Jared Hasson Jared Hasson Full time lead founding dev at a cyber security saas startup, with 10 yoe and a bachelor's in CS. Building & debugging software products is what I've spent my time on for forever rayush33 rayush33 JavaScript (React.js, React Native, Node.js) Developer with demonstrated industry experience of 4+ years, actively looking for opportunities to hone my skills as well as help small-scale business owners with solutions to technical problems Bastien Labelle Bastien Labelle Full stack dev w/ 20+ years of experience prajwalfullstack prajwalfullstack Hi Im a full stack developer, a vibe coded MVP to Market ready product, I'm here to help BurnHavoc BurnHavoc Been around fixing other peoples code for 20 years. Pratik Pratik SWE with 15+ years of experience building and maintaining web apps and extensive BE infrastructure Krishna Sai Kuncha Krishna Sai Kuncha Experienced Professional Full stack Developer with 8+ years of experience across react, python, js, ts, golang and react-native. Developed inhouse websearch tooling for AI before websearch was solved : ) Dor Yaloz Dor Yaloz SW engineer with 6+ years of experience, I worked with React/Node/Python did projects with React+Capacitor.js for ios Supabase expert

You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.

Get Help

Frequently Asked Questions

What is the difference between HttpOnly, Secure, and SameSite?

HttpOnly prevents JavaScript access to the cookie (blocks XSS theft). Secure ensures the cookie is only sent over HTTPS. SameSite controls whether cookies are sent with cross-site requests (blocks CSRF). You need all three for proper security.

Should I use localStorage or cookies for auth tokens?

Cookies with HttpOnly and Secure flags are safer for auth tokens because JavaScript cannot access them, making XSS attacks ineffective. localStorage is readable by any script on the page, so a single XSS vulnerability exposes all tokens.

Related Bolt Issues

Can't fix it yourself?
Real developers can help.

You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.

Get Help