Skill de Sécurité des Tokens Mapbox

Ce skill fournit une expertise en sécurité pour gérer les tokens d'accès Mapbox de manière sûre et efficace.

Types de Tokens et Quand les Utiliser

Tokens Publics (pk.*)

Caractéristiques :

• Peuvent être exposés sans risque dans le code côté client
• Limités à des scopes publics spécifiques uniquement
• Peuvent avoir des restrictions d'URL
• Ne peuvent pas accéder aux APIs sensibles

Quand les utiliser :

• Applications web côté client
• Applications mobiles
• Démonstrations publiques
• Cartes intégrées sur des sites web

Scopes autorisés :

• styles:tiles - Afficher les tuiles de style (raster)
• styles:read - Lire les spécifications de style
• fonts:read - Accéder aux polices Mapbox
• datasets:read - Lire les données des datasets
• vision:read - Accès à l'API Vision

Tokens Secrets (sk.*)

Caractéristiques :

• NE JAMAIS exposer dans le code côté client
• Accès complet à l'API avec tous les scopes
• Utilisation côté serveur uniquement
• Peuvent créer/gérer d'autres tokens

Quand les utiliser :

• Applications côté serveur
• Services backend
• Pipelines CI/CD
• Tâches administratives
• Gestion des tokens

Scopes courants :

• styles:write - Créer/modifier les styles
• styles:list - Lister tous les styles
• tokens:read - Afficher les informations des tokens
• tokens:write - Créer/modifier les tokens
• Scopes de gestion des retours utilisateur

Tokens Temporaires (tk.*)

Caractéristiques :

• Courte durée de vie (max 1 heure)
• Créés par les tokens secrets
• Utilisation mono-usage
• Expiration automatique

Quand les utiliser :

• Opérations ponctuelles
• Accès délégué temporaire
• Démonstrations courte durée
• Workflows soucieux de sécurité

Bonnes Pratiques de Gestion des Scopes

Principe du Moindre Privilège

Accordez toujours les scopes minimums nécessaires :

❌ Mauvais :

// Trop permissif - ne pas faire cela
{
  scopes: ['styles:read', 'styles:write', 'styles:list', 'styles:delete', 'tokens:read', 'tokens:write'];
}

✅ Bon :

// Seulement ce qui est nécessaire pour afficher une carte
{
  scopes: ['styles:read', 'fonts:read'];
}
// Ajouter 'styles:tiles' si votre carte utilise des sources de tuiles raster
{
  scopes: ['styles:read', 'fonts:read', 'styles:tiles'];
}

Combinaisons de Scopes par Cas d'Usage

Affichage de Carte Publique (côté client) :

{
  "scopes": ["styles:read", "fonts:read", "styles:tiles"],
  "note": "Token public pour l'affichage de carte",
  "allowedUrls": ["https://myapp.com/*"]
}

Gestion des Styles (côté serveur) :

{
  "scopes": ["styles:read", "styles:write", "styles:list"],
  "note": "Gestion des styles backend - TOKEN SECRET"
}

Administration des Tokens (côté serveur) :

{
  "scopes": ["tokens:read", "tokens:write"],
  "note": "Gestion des tokens uniquement - TOKEN SECRET"
}

Accès en Lecture Seule :

{
  "scopes": ["styles:list", "styles:read", "tokens:read"],
  "note": "Audit/monitoring - TOKEN SECRET"
}

Restrictions d'URL

Pourquoi les Restrictions d'URL Sont Importantes

Les restrictions d'URL limitent les endroits où un token public peut être utilisé, empêchant l'utilisation non autorisée si le token est exposé.

Motifs d'URL Efficaces

✅ Motifs recommandés :

https://myapp.com/*           # Domaine de production
https://*.myapp.com/*         # Tous les sous-domaines
https://staging.myapp.com/*   # Environnement de staging
http://localhost:*            # Développement local

❌ À éviter :

*                             # Aucune restriction (non sécurisé)
http://*                      # N'importe quel site HTTP (non sécurisé)
*.com/*                       # Trop large

Stratégie Multi-Environnements

Créez des tokens distincts pour chaque environnement :

// Production
{
  note: "Production - myapp.com",
  scopes: ["styles:read", "fonts:read"],
  allowedUrls: ["https://myapp.com/*", "https://www.myapp.com/*"]
}

// Staging
{
  note: "Staging - staging.myapp.com",
  scopes: ["styles:read", "fonts:read"],
  allowedUrls: ["https://staging.myapp.com/*"]
}

// Développement
{
  note: "Development - localhost",
  scopes: ["styles:read", "fonts:read"],
  allowedUrls: ["http://localhost:*", "http://127.0.0.1:*"]
}

Stockage et Gestion des Tokens

Côté Serveur (Tokens Secrets)

✅ À FAIRE :

• Stocker dans les variables d'environnement
• Utiliser les services de gestion des secrets (AWS Secrets Manager, HashiCorp Vault)
• Chiffrer au repos
• Limiter l'accès via les politiques IAM
• Enregistrer l'utilisation des tokens

❌ À NE PAS FAIRE :

• Coder en dur dans le code source
• Valider dans le contrôle de version
• Stocker dans des fichiers de configuration en plaintext
• Partager par email ou Slack
• Réutiliser sur plusieurs services

Exemple : Variable d'Environnement Sécurisée :

# .env (NE JAMAIS valider ce fichier)
MAPBOX_SECRET_TOKEN=sk.ey...

# .gitignore (TOUJOURS inclure .env)
.env
.env.local
.env.*.local

Côté Client (Tokens Publics)

✅ À FAIRE :

• Utiliser uniquement des tokens publics
• Appliquer les restrictions d'URL
• Utiliser des tokens différents par application
• Effectuer une rotation périodiquement
• Surveiller l'utilisation

❌ À NE PAS FAIRE :

• Exposer les tokens secrets
• Utiliser des tokens sans restrictions d'URL
• Partager les tokens entre applications sans rapport
• Utiliser des tokens avec trop de scopes

Exemple : Utilisation Sûre Côté Client :

// Token public avec restrictions d'URL - SÛR
const mapboxToken = 'pk.YOUR_MAPBOX_TOKEN_HERE';

// Ce token est restreint à votre domaine
// et n'a que le scope styles:read
mapboxgl.accessToken = mapboxToken;

Checklist de Sécurité

Création de Token :

• [ ] Utiliser des tokens publics pour côté client, secrets pour côté serveur
• [ ] Appliquer le principe du moindre privilège pour les scopes
• [ ] Ajouter les restrictions d'URL aux tokens publics
• [ ] Utiliser des noms/notes descriptifs pour l'identification des tokens
• [ ] Documenter l'utilisation prévue et l'environnement

Gestion des Tokens :

• [ ] Stocker les tokens secrets dans les variables d'environnement ou les gestionnaires de secrets
• [ ] Ne jamais valider les tokens dans le contrôle de version
• [ ] Effectuer une rotation des tokens tous les 90 jours (ou selon la politique)
• [ ] Supprimer les tokens inutilisés rapidement
• [ ] Séparer les tokens par environnement (dev/staging/prod)

Surveillance :

• [ ] Suivre les motifs d'utilisation des tokens
• [ ] Mettre en place des alertes pour les activités inhabituelles
• [ ] Audits de sécurité réguliers (mensuels)
• [ ] Examiner l'accès de l'équipe trimestriellement
• [ ] Scanner les repositories pour les tokens exposés

Réponse aux Incidents :

• [ ] Procédure de révocation documentée
• [ ] Liste des contacts d'urgence
• [ ] Processus de rotation documenté
• [ ] Modèle d'examen post-incident
• [ ] Formation de l'équipe sur les procédures de sécurité

Fichiers de Référence

Pour des conseils détaillés sur des sujets spécifiques, chargez ces références selon les besoins :

• references/rotation-monitoring.md — Stratégies de rotation des tokens (sans downtime + urgence), métriques de surveillance, règles d'alerte et checklists d'audit mensuels/trimestriels. Charger quand : implémenter la rotation, configurer la surveillance ou conduire des audits.
• references/incident-response.md — Plan de réponse aux incidents étape par étape et erreurs de sécurité courantes avec exemples de code. Charger quand : répondre à un compromis de token, examiner le code pour les problèmes de sécurité ou former aux anti-patterns.

Quand Utiliser Ce Skill

Invoquez ce skill quand :

• Créer de nouveaux tokens
• Décider entre tokens publics et secrets
• Configurer les restrictions de tokens
• Implémenter la rotation des tokens
• Enquêter sur les incidents de sécurité
• Conduire des audits de sécurité
• Former l'équipe sur la sécurité des tokens
• Examiner le code pour l'exposition des tokens