# Architecture securite ORASKY

Ce document decrit la direction securite pour une vraie application ORASKY avec comptes utilisateurs, mots de passe, signalements et GPS.

Important: la version actuelle dans `index.html` est une maquette locale. Elle ne doit pas stocker de vrais mots de passe ni de vraies positions GPS. Pour une mise en production, il faut un backend securise.

## Principes obligatoires

1. Ne jamais stocker de mot de passe en clair.
2. Ne jamais stocker les mots de passe dans le navigateur.
3. Ne jamais faire confiance au client: toutes les permissions doivent etre verifiees cote serveur.
4. Chiffrer les communications avec HTTPS/TLS.
5. Limiter la collecte GPS au strict necessaire.
6. Journaliser les actions critiques sans exposer les donnees sensibles.
7. Prevoir la detection d'abus: brute force, bots, credential stuffing, scraping de GPS.

## Collecte emails pre-lancement

Pour batir l'application, ORASKY peut recueillir des emails avec une liste d'attente. Cette collecte doit rester minimale:

- email;
- profil general;
- interet principal;
- message optionnel;
- consentement avec date.

Ne pas demander de mot de passe ni de position GPS a cette etape. L'export des emails doit etre reserve a un administrateur protege par MFA.

## Authentification

Recommandation:

- utiliser un fournisseur d'identite gere comme Auth0, Clerk, Firebase Auth, Supabase Auth, AWS Cognito ou Microsoft Entra External ID;
- activer MFA pour les comptes sensibles;
- accepter les passphrases longues;
- bloquer les mots de passe connus comme compromis;
- utiliser des sessions securisees avec expiration et rotation;
- demander une reauthentification pour les actions sensibles.

Si ORASKY gere les mots de passe lui-meme:

- hachage Argon2id;
- sel unique par utilisateur;
- pepper conserve dans un gestionnaire de secrets;
- jamais de MD5, SHA1, SHA256 simple ou bcrypt mal configure;
- reset password par jeton court, expire rapidement, usage unique.

## Autorisation

Roles minimaux:

- `citizen`: creer ses propres observations, voir les alertes publiques;
- `moderator`: confirmer, rejeter, masquer des signalements;
- `responder`: voir les alertes prioritaires autorisees;
- `admin`: gestion operationnelle, pas acces direct aux secrets;
- `security_admin`: audit, incidents, politiques.

Chaque API doit verifier:

- l'utilisateur est authentifie;
- le role est autorise;
- la ressource appartient a l'utilisateur ou a son groupe;
- l'action est permise pour cette zone geographique.

## Donnees GPS

Les positions GPS sont sensibles.

Mesures recommandees:

- demander consentement explicite;
- expliquer pourquoi la position est demandee;
- permettre de publier en position approximative;
- arrondir ou flouter les coordonnees publiques;
- separer coordonnees exactes et donnees publiques;
- supprimer ou anonymiser selon une politique de retention;
- ne jamais afficher la position exacte d'un utilisateur sans raison operationnelle.

Mode public recommande:

- position exacte conservee temporairement cote serveur;
- carte publique affichee avec precision reduite;
- acces exact reserve aux roles autorises.

## Donnees environnementales exploitables

Les observations ORASKY peuvent devenir des donnees utiles pour les services environnementaux, les municipalites, les chercheurs et les equipes de prevention.

Exemples:

- avalanche jamais repertoriee officiellement;
- zone d'inondation connue localement;
- fumee inhabituelle;
- faune en danger;
- route ou territoire a risque.

Ces donnees doivent etre separees par niveau de sensibilite:

- donnees publiques approximatives;
- donnees exactes reservees;
- temoignages anonymises;
- preuves media moderees;
- historique d'audit.

## API et backend

Backend recommande:

- API REST ou GraphQL avec validation stricte;
- rate limiting par IP, compte et appareil;
- anti-bot sur login et creation de compte;
- protection CSRF si cookies de session;
- CORS restrictif;
- validation cote serveur de tous les champs;
- requetes SQL parametrees;
- journaux d'audit immuables pour actions critiques;
- detection d'anomalies.

## Base de donnees

Tables minimales:

- users
- sessions
- roles
- observations
- observation_confirmations
- gps_events
- audit_logs
- moderation_actions

Protection:

- chiffrement au repos;
- sauvegardes chiffrees;
- acces admin limite;
- rotation des secrets;
- suppression/anonymisation automatique des donnees GPS anciennes.

## Infrastructure

Minimum production:

- HTTPS obligatoire;
- WAF/CDN avec protection DDoS;
- secrets dans vault ou gestionnaire de secrets;
- dependances scannees;
- CI/CD avec tests securite;
- alertes sur erreurs 401/403/429/500 anormales;
- sauvegardes testees;
- plan de reponse a incident.

## Carte GPS

Options:

- Mapbox
- Google Maps Platform
- HERE
- Azure Maps
- Leaflet + OpenStreetMap

Pour une premiere version, Leaflet/OpenStreetMap est economique. Pour une version commerciale avec SLA, Mapbox/Google/Azure peuvent etre preferables.

## Regles avant lancement public

- Audit de code.
- Test d'intrusion.
- Revue OWASP Top 10 et OWASP API Security Top 10.
- Politique de confidentialite.
- Conditions d'utilisation.
- Systeme de signalement d'abus.
- Moderation des signalements publics.
- Procedure de suppression de compte et donnees.

## Ce que la maquette fait maintenant

- Montre une interface de carte.
- Montre les scenarios ORASKY.
- Ajoute une zone securite/GPS.
- Ne stocke aucun vrai mot de passe.
- Ne transmet aucune position a un serveur.

## Prochaine etape technique

Construire un vrai backend avec:

- authentification;
- base de donnees;
- API securisee;
- carte GPS reelle;
- systeme de signalement;
- roles et permissions.

## References securite

- OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
- OWASP Password Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- OWASP API Security Top 10 2023: https://owasp.org/API-Security/editions/2023/en/0x11-t10/