Bundle ID Pinning

Un token pio_live_... est embarqué dans le bundle de ton app — il est donc extractible par n’importe qui qui décompile l’IPA/APK. Pionne contre ce risque avec un mécanisme de pinning automatique du Bundle ID.

Mobile uniquement

Cette protection ne s’applique qu’aux SDKs iOS, Android, React Native et Flutter — les seuls qui livrent un binaire décompilable contenant le token. Pour les SDKs Web, Node.js, Laravel et Symfony, le token vit côté serveur (.env, secrets manager) ou dans l’environnement du visiteur, jamais dans un binaire — la menace que ce mécanisme adresse n’existe pas. Le champ “Bundle ID (optionnel)” est donc masqué pour ces projets dans l’app mobile (depuis 2026-05-08), et le remplir manuellement via l’API PATCH /projects/:id causerait un 403 sur 100 % des events (le SDK n’envoie pas de app_id). Voir Backends sans bundle_id plus bas.

Le risque

1. Un attaquant extrait ton token de l’APK.
2. Il l’utilise depuis sa propre app pour spammer ton ingest.
3. Tu manges ton quota de 50k events/mois sur du bruit.

La protection

Étape 1 — premier event

Le tout premier event reçu sur un projet contient un app_id (le Bundle ID iOS / Application ID Android). Pionne fige cette valeur dans le champ bundle_id du projet.

Projet "Acme iOS"
  bundle_id: null  →  premier event { app_id: "com.acme.app" }  →  bundle_id: "com.acme.app" (figé)

Étape 2 — events suivants

À chaque event, le serveur compare le app_id du payload avec le bundle_id du projet :

app_id reçu	bundle_id projet	Réponse
com.acme.app	com.acme.app	202 Accepted
com.attacker.app	com.acme.app	403 Forbidden

L’attaquant aura beau utiliser ton token, son app a un autre Bundle ID — donc rejeté.

Modifier le bundle_id pinné

Si tu changes de Bundle ID légitimement (rebrand, fusion d’apps), va dans Settings → Project → Bundle ID dans l’app mobile Pionne et change la valeur. Le prochain event avec le nouveau Bundle ID sera accepté.

Attention

Tu peux aussi le mettre à null pour forcer un re-pinning au prochain event. Fais-le hors période de prod : pendant la fenêtre où c’est null, n’importe quel app_id peut le re-pinner.

Cas Expo Go / dev

En Expo Go, l’app_id rapporté est celui d’Expo (host.exp.Exponent ou similaire). Si tu testes avec Expo Go avant de release ton app, prévois un projet Pionne séparé pour le dev, sinon tu vas pinner sur le Bundle ID d’Expo.

Pionne.init({
  token: __DEV__
    ? process.env.EXPO_PUBLIC_PIONNE_TOKEN_DEV
    : process.env.EXPO_PUBLIC_PIONNE_TOKEN_PROD,
});

Backends sans bundle_id

Sur Web/Node/Laravel/Symfony, ton token n’est jamais shippé à un client : il vit dans .env (gitignored), un secrets manager (AWS Secrets, Vault, EAS env vars…), ou la mémoire du process serveur. Personne ne peut “décompiler” un container Docker ou ton FPM PHP pour le récupérer — pour cela il faudrait déjà un accès root au serveur, et à ce stade le token est le moindre des problèmes.

Conséquence : laisse le champ Bundle ID vide sur ces projets. Et pour différencier des déploiements (prod-eu vs prod-us, staging…), utilise les tags côté SDK plutôt qu’un identifiant pinné côté serveur :

// Laravel / Symfony
Pionne::init([
    'token' => env('PIONNE_TOKEN'),
    'tags'  => [
        'deployment' => env('APP_DEPLOYMENT', 'prod'),
        'region'     => env('AWS_REGION', 'eu-west-3'),
    ],
]);

Node.js

Pionne.init({
  token: process.env.PIONNE_TOKEN,
  tags: { deployment: process.env.APP_DEPLOYMENT ?? 'prod' },
});

Les tags arrivent indexés sur l’event, tu peux filtrer/grouper dessus dans le dashboard sans bloquer l’ingest.

En complément

Le bundle pinning n’est qu’une couche. Combine avec :

• Tokens → régénère ton token si tu suspectes une fuite.
• Privacy → minimise ce qui est dans le payload.
• Rate limits → cap par token côté serveur, token bucket côté SDK.

Voir aussi

• Tokens
• Rate limits
• API Ingest
• Privacy