Sécurité et authentification

La sécurité repose sur plusieurs frontières complémentaires. Une protection d’interface améliore l’expérience ; seules les validations serveur et backend constituent une autorisation.

Modèle de confiance

Entrée non fiable
  navigateur · URL · formulaire · fichier · feed iCalendar · réponse fournisseur
        ↓ validation et limites
SvelteKit serveur
        ↓ authentification transportée côté serveur
API backend
        ↓ autorisation + règles métier
PocketBase et adaptateurs externes

Traitez toute valeur reçue comme non fiable, y compris un champ renvoyé par un service tiers ou une ancienne version de l’application.

Flux de connexion back-office

1. Le mot de passe démarre un challenge de cinq minutes.
2. Un compte déjà configuré fournit un code TOTP ou un code de récupération.
3. Une première connexion enregistre un secret TOTP puis confirme un code.
4. Le backend émet un token de session seulement après le second facteur.
5. SvelteKit stocke ce token dans harmony_backoffice_session, cookie httpOnly.
6. hooks.server.ts vérifie la session et remplit locals à chaque requête.

Les cookies sont sameSite=lax, secure hors dev et limités au chemin /. L’option « se souvenir » donne une durée maximale de sept jours ; sinon la session suit le navigateur.

Défense en profondeur

Pour chaque page ou mutation back-office :

• le layout redirige un utilisateur non connecté ;
• le load, l’action ou l’endpoint vérifie lui-même le token et l’utilisateur ;
• la règle de rôle est appliquée côté SvelteKit lorsque la réponse dépend de ce rôle ;
• le backend répète authentification et autorisation ;
• le domaine refuse les transitions interdites indépendamment du transport.

Un champ roles dans la navigation est cosmétique. Une action masquée reste appelable par une requête forgée si les contrôles serveur sont absents.

Secrets et variables

Secret	Emplacement autorisé
API_TOKEN	environnement serveur SvelteKit
bearer token utilisateur	cookie httpOnly puis header serveur
HARMONY_TOTP_ENCRYPTION_KEY	secret runtime backend stable
HARMONY_CALENDAR_ENCRYPTION_KEY	secret runtime backend stable et distinct
HARMONY_OPENAI_API_KEY	adaptateur backend uniquement
mot de passe SMTP	configuration backend protégée

Ne placez jamais un secret dans une variable PUBLIC_*, une story, un fixture, un log, une capture, un paramètre d’URL ou le contrat OpenAPI. Les clés MapTiler sont publiques et doivent être limitées par domaines et quotas chez le fournisseur.

Validation des entrées

• Bornez la taille des corps, listes et fichiers.
• Validez enums, identifiants, slugs, locales, dates et nombres avant usage.
• Encodez les segments d’URL et construisez les query strings avec les API prévues.
• Refusez les redirections qui ne restent pas sous le chemin back-office autorisé.
• Autorisez explicitement les chemins de fichiers servis par proxy.
• Analysez format et taille d’un média avant traitement.
• Prévisualisez et validez un feed externe avant de le persister.

La validation client donne un retour rapide, mais la validation serveur reste obligatoire.

Autorisation par rôle

Profil	Intention
author	production de contenus autorisés
manager	exploitation courante, demandes, équipe et calendriers
admin	configuration globale et opérations les plus sensibles

Ajoutez un test par rôle pour toute nouvelle règle. Testez aussi l’absence de session et un rôle inconnu ou suspendu.

Données personnelles

Les demandes de contact, réservations, comptes et audits peuvent identifier une personne. Appliquez les principes suivants :

• minimisation des champs collectés et retournés ;
• accès limité au besoin opérationnel ;
• export et logs sans données inutiles ;
• archivage distinct de la suppression ;
• suppression selon la politique de conservation ;
• fixtures exclusivement fictives.

Les audits IA ne contiennent ni texte source, ni réponse générée, ni prompt complet. Un hash sert à la corrélation sans permettre de reconstruire le contenu.

Téléversements et médias

N’accordez pas de confiance au nom, MIME déclaré ou extension. Vérifiez format, poids et contenu selon le pipeline média. Servez les fichiers avec les en-têtes appropriés et empêchez la traversée de répertoire. Un SVG importé doit suivre la politique de traitement du backend avant exposition.

Services externes

Les erreurs SMTP, IA ou iCalendar sont normalisées avant journalisation et réponse. N’enregistrez pas les URL secrètes de calendrier ou les corps envoyés à un fournisseur. Définissez des timeouts et respectez l’annulation de contexte.

Revue sécurité avant PR

• Aucun token ou secret n’atteint le bundle client.
• Chaque load, action et endpoint protégé vérifie la session.
• Chaque règle de rôle est testée côté serveur et backend.
• Les entrées et tailles sont bornées.
• Les chemins, URLs et redirections sont validés.
• Les erreurs publiques ne révèlent aucun détail interne.
• Les logs et fixtures ne contiennent pas de données réelles.
• Les mutations concurrentes utilisent la protection expectedUpdatedAt si applicable.
• OpenAPI documente l’authentification et les erreurs.

En cas de secret commité, considérez-le compromis : révoquez-le immédiatement, puis nettoyez son usage. Retirer la chaîne du dernier commit ne suffit pas à annuler sa divulgation.