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.

Le risque

Un attaquant extrait ton token de l’APK.
Il l’utilise depuis sa propre app pour spammer ton ingest.
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é.

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,
});

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 limiting serveur : 1000 events/min/token.