Un modèle de sécurité lisible, avec ses limites
PWA2APP manipule vos clés de signature et le code de vos applications. Voici ce qui est en place aujourd'hui, et ce qui ne l'est pas encore.
Vos clés de signature
Les clés Android (keystore, mots de passe) sont chiffrées avec un chiffrement en enveloppe AES-256-GCM. Chaque secret a sa propre enveloppe, liée à votre organisation et à la clé concernée : une enveloppe copiée ailleurs ne se déchiffre pas.
- Seul le service de signature reçoit le matériel d'une clé, pour un job donné, et chaque utilisation est journalisée.
- Une clé révoquée voit ses secrets détruits ; la révocation demande une confirmation par mot de passe.
- Les clés générées par PWA2APP sont créées dans la zone de signature ; vous pouvez aussi importer les vôtres.
Build et signature séparés
Le build est exécuté par un worker de compilation. La signature d'une version de production est faite par un autre service, dédié. Le worker de build ne détient jamais vos clés.
- Les workers communiquent avec l'orchestrateur par TLS mutuel, avec des certificats de courte durée.
- Les workers n'ont aucun accès à la base de données.
- La configuration embarquée dans l'application est signée par l'orchestrateur ; le worker ne détient pas la clé qui la signe.
- Les processus de compilation s'exécutent avec un environnement vidé de toute variable sensible.
Ce que PWA2APP ne voit pas
PWA2APP ne stocke ni vos mots de passe en clair, ni les données de vos utilisateurs finaux. Les applications générées ne collectent aucune donnée personnelle de l'utilisateur final.
Protection des imports
- Les adresses importées passent par un récupérateur protégé contre les attaques SSRF : plages privées, adresses de métadonnées cloud et redirections vers l'interne sont refusées.
- Les archives sont extraites avec des protections contre les chemins piégés, les liens symboliques et les archives explosives.
- Pour une version de production, vous devez prouver que vous contrôlez le domaine de la PWA.
Comptes et accès
- Double authentification par application TOTP, codes de secours et clés d'accès (passkeys).
- Les actions sensibles (révocation d'une clé, suppression) demandent de confirmer votre identité.
- Sessions par cookies protégés (HttpOnly, SameSite) et protection contre le CSRF.
- Isolation des organisations au niveau de la base de données (sécurité par ligne) : chaque requête est limitée à une organisation.
- Un journal d'activité conserve les actions importantes de l'organisation.
Ce site
Ce site est statique : aucun compte, aucun mot de passe, aucun cookie de suivi, aucun script tiers. Une politique de sécurité de contenu stricte l'empêche de charger quoi que ce soit d'extérieur. Les liens « Se connecter » mènent vers l'application, jamais vers un formulaire de ce site.
Limites assumées
- Le Bridge n'est pas testé sur appareils réels à ce jour.
- Aucun audit de sécurité indépendant n'a encore été réalisé.
Aucune protection embarquée dans une application n'est inviolable : quelqu'un qui recompile l'application peut modifier son contenu. Le serveur reste l'autorité. De plus, le service de gestion de clés (KMS) de production n'est pas encore arrêté : en développement, le chiffrement en enveloppe s'appuie sur un module local.
Signaler une vulnérabilité
Écrivez à security@pwa2app.tech. Le fichier security.txt du site décrit le contact et la politique de divulgation. Nous accusons réception et vous tenons informé de la correction.