How to securely store Mapbox API token in Leaflet.js plugin config for Sanity?

13 replies
Last updated: Sep 6, 2021
for anyone who uses the Leaflet.js map input plugin with mapbox, how do you store the the mapbox api token securely? If you are like me and check in all your studio config, the leaflet.js plugin creates a
leaflet-input.json
file for you to interact and configure the plugin with. One of the fields is 'accessToken', and im not sure how to both check in this file, all while giving leaflet access to my token (its just a json file, its not a .js file, so i cant access env vars or import the token from some keystore)
AI Update

Great question! This is a common concern when working with the Leaflet.js map input plugin and Mapbox. The good news is that Mapbox access tokens are actually designed to be checked into your codebase when properly secured.

Instead of treating your Mapbox token like a traditional secret, you should secure it using Mapbox's URL restrictions feature. Here's how it works:

  1. Lock the token to your Studio domain: In your Mapbox account settings, configure URL restrictions for your access token. This means the token will only work when requests come from your specific Sanity Studio domain (e.g., your-studio.sanity.studio).

  2. Use multiple tokens for different environments: Create separate tokens for:

    • Production (locked to your production Studio URL)
    • Development (locked to localhost:3333 or your local dev URL)
    • Staging (if applicable)
  3. Check the config file into your repo: Once the token is URL-restricted, you can safely commit your config/leaflet-input.json file with the accessToken field. The token becomes useless to anyone who doesn't have access to your specific Studio domain.

Additional Security Considerations

According to the Sanity team's guidance, you should:

  • Keep your repository private if possible (though URL restrictions provide the primary security)
  • The URL restrictions make the token effectively useless outside your Studio environment

If you absolutely need to avoid checking in the token, you could use the sanity-secrets plugin, but this adds complexity and isn't the standard approach for Mapbox tokens since they're designed to work with URL restrictions.

The URL restriction approach is actually the intended security model for client-side Mapbox tokens - similar to how you'd secure a Google Maps API key. It's not a workaround, it's the proper solution!

Show original thread
13 replies
Sanity team recommended using something like this: https://www.npmjs.com/package/sanity-secrets
thanks, this is great. Any idea where you store the provided example config? It seems this provides a means to input your secrets from studio? And where would i add this component if so, deskStructure.js?
It looks like
accessToken
lives in the JSON file and you use URL restrictions on the Mapbox side to secure it—similar to Simeon’s suggestion for Google Maps .
interesting, i didnt know about this! So its a unique access token than i can checkin without fear of others using it that only i can use, makes sense
Yes, that’s the way I understand it.
so essentially, this URL would be my custom sanity studio domain?
Correct. You would lock it down to your production studio domain. This page recommends using multiple tokens to handle different environments (e.g., to open up localhost in development).
great article, and makes sense, a key for each env
so they seem safe to checkin then
If you want to be absolutely sure and can wait until tomorrow, I can double-check, but yes, I am fairly confident these are not just safe but required to be checked in.
thanks geoff!
Got confirmation: Lock the key to the same domain as the studio and make sure your repo is private, and you should be golden.
thank you again, hmm my repo is public, do you think that should be a big deal given these are locked to the domain?

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?