Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

294
Vistas
SWR exposes client-id and Bearer tokens in every api call, I should be concered right

Long story short I have just somewhat finished building an application with NextJs, NextAuth and SWR, I use SWR to call multiple Twitch API's, to authenticate the Twitch API I use my Twitch applications Client-Id, and the logged in users Bearer token which is taken from the NextAuth's session object.

My concern is whenever SWR performs and API function to populate the page with data or update it, you can easily view the request headers when capturing the network calls in chrome or firefox dev tools here. This is majorly concerning that this is a production environment and it still happens, this also violates Twitch developers documentation and pretty sure there tos "Warning: Treat your token like a password. For example, never use access tokens in any public URL, and never display tokens on any web page without requiring a click to de-obfuscate."

Is there a way or solution to hiding these?

Now my next best question is how can I stop this from happening and is their even a way?

about 4 years ago · Juan Pablo Isaza
1 Respuestas
Responde la pregunta

0

No need to be alarmed. It's ok to include Bearer tokens in the request's Authorization header - in fact that's the standard way to send them. You can't hide it from Chrome's Dev Tools as that would defeat its purpose.

The advice you read never use access tokens in any public URL might mean don't ever display them in a URL like mywebsite.com/?token=[abcd] because then it would be accessible via browser history, or don't send a token designed for one service to another service's API.

This has nothing to do with SWR - it's standard HTTP behaviour.

about 4 years ago · Juan Pablo Isaza Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda