Navigateur et mobile

Cette page regroupe les protections côté client : en-têtes HTTP et politique de sécurité du contenu (CSP) du frontend web, configuration du site statique de l'Office de Tourisme, et stockage sécurisé de l'application mobile. Les détails d'implémentation propres à chaque application sont dans Sécurité du navigateur, Authentification et stockage sécurisé et Accessibilité et vie privée.

#Frontend web

Les en-têtes sont déclarés dans la fonction headers() de frontend-web/next.config.mjs et appliqués à toutes les routes (/:path*).

#En-têtes

Next.js est aussi configuré avec poweredByHeader: false (pas d'en-tête X-Powered-By) et productionBrowserSourceMaps: false (pas de source map publique). La CI vérifie qu'aucun fichier .map ni aucun motif de secret ne figure dans .next/static.

#Politique CSP

La politique est construite à partir de NEXT_PUBLIC_API_URL et NEXT_PUBLIC_WS_URL, dont seule l'origine est retenue :

connect-src limite les destinations des appels réseau : un script injecté ne peut pas exfiltrer de données vers un autre domaine par fetch ou WebSocket. frame-ancestors 'none' et X-Frame-Options: DENY empêchent l'intégration du site dans une iframe (clickjacking).

En développement, aucune CSP n'est envoyée, pour laisser fonctionner le rechargement à chaud.

#Autres mesures

#Site de l'Office de Tourisme

Le site est statique (HTML, CSS, modules JavaScript) et servi par nginx non privilégié. La configuration est dans frontend-office-tourisme/docker/nginx.conf et frontend-office-tourisme/docker/security-headers.conf.

#En-têtes

La CSP du site est plus stricte que celle du web : aucun script en ligne n'est autorisé (script-src 'self'), et seuls les attributs style en ligne le sont (style-src-attr 'unsafe-inline'), pas les balises <style>. Toutes les ressources (polices Inter et Jost, bibliothèque qrcode-generator, photos) sont servies par le site lui-même.

Le fichier d'en-têtes est inclus au niveau du serveur et dans chaque bloc location qui ajoute ses propres en-têtes. Ce doublement est nécessaire : dans nginx, une directive add_header dans un bloc location annule celles héritées du niveau supérieur.

#Durcissement nginx

#Serveur de développement

npm run dev sert le site avec serve et frontend-office-tourisme/serve.json. Ce fichier n'applique qu'une partie des en-têtes (CSP, X-Content-Type-Options, Referrer-Policy, X-Frame-Options) aux pages HTML. Les en-têtes complets ne sont garantis que par l'image nginx.

#Données dans le navigateur

Le site n'envoie aucune donnée à un serveur. Panier, favoris, commandes de démonstration, inscription à la newsletter et choix du bandeau cookies sont stockés dans le localStorage. La billetterie ne demande aucune coordonnée bancaire. Les modules qui construisent du HTML échappent les valeurs avec escapeHtml de frontend-office-tourisme/assets/js/modules/utils.js. Le bandeau est décrit dans Cookies, mentions et CGU.

#Application mobile

#Stockage sécurisé

mobile-app/src/services/secureStorage.ts enregistre le jeton (blocklucky_jwt_token) et le profil (blocklucky_user_profile) avec expo-secure-store :

Une copie du jeton est aussi gardée dans un cache mémoire du module, vidé à la fermeture de l'application. Les erreurs d'écriture dans le stockage sécurisé sont ignorées silencieusement. L'application ne relit de toute façon pas la session au démarrage : le jeton reste stocké mais l'utilisateur doit se reconnecter. À la déconnexion, le jeton et le profil sont effacés après l'appel à POST /api/auth/logout. Aucun mot de passe n'est stocké sur l'appareil.

#Connexion Google

Le mobile obtient le jeton d'identité par expo-auth-session (Google, avec les identifiants EXPO_PUBLIC_GOOGLE_IOS_CLIENT_ID, EXPO_PUBLIC_GOOGLE_ANDROID_CLIENT_ID et EXPO_PUBLIC_GOOGLE_WEB_CLIENT_ID), puis le transmet au backend, qui le vérifie (SocialAuthButtons.tsx). L'application ne garde pas ce jeton. Les identifiants client sont publics par nature ; ils figurent vides dans mobile-app/.env.example. Sans eux, ou si le backend répond 503, le bouton Google est désactivé.

#Photos de la pièce d'identité

VerifyAgeScreen.tsx prend le recto et le verso avec l'appareil photo ou les choisit dans la galerie (expo-image-picker, autorisations demandées au moment de l'usage, textes d'explication déclarés dans app.json). Les images sont lues en base64, sans métadonnées EXIF (exif: false), refusées au-delà de 4 Mo, puis envoyées en HTTPS par POST /api/user/identity et retirées de l'état de l'écran après l'envoi. Le sélecteur dépose aussi une copie de chaque image dans le cache de l'application (asset.uri), que le code ne supprime pas. Une photo prise dans la galerie y reste, puisqu'elle appartient au citoyen.

#Configuration

#Ce qui n'est pas en place

Ces absences sont acceptables pour un pilote sur réseau de test. Elles redeviennent prioritaires si l'application manipule des fonds réels, la clé de portefeuille restant de toute façon côté serveur.