DocsConventions et concepts

Sécurité

Comment Nexy maintient sa propre surface d'attaque petite, quelles versions il nécessite et comment vérifier un projet.

Planchers de version

Nexy dépend de FastAPI, Starlette, Jinja2, Vite et React. Un plancher est la version la plus basse autorisée par Nexy ; chacun répond à un avis publié.

Forfait	Sol	Pourquoi
`starlette`	1.0.1	CVE-2026-48710 (BadHost) : un en-tête `Host` contrefait modifie le chemin d'accès Starlette vers le middleware, qui contourne l'autorisation écrite sur `request.url.path`. Répertorié comme exploité par CISA.
`fastapi`	0.133.0	la première version qui accepte un Starlette fixe
`jinja2`	3.1.6	le bac à sable s'échappe à travers le filtre `attr` (CVE-2025-27516)
`vite` (projets échafaudés)	6.4.3	`server.fs.deny` contourner les chemins alternatifs Windows (CVE-2026-53571) ; le contournement de chaîne de requête antérieur (CVE-2026-39364) affecte uniquement Vite 7.1-7.3.1 et 8.0.0-8.0.4
`react`, `react-dom`	19.2.5	les avis 2026 React concernent les packages `react-server-dom-*`, que Nexy n'utilise pas ; le sol maintient la ligne réparée

Vérifiez vos versions résolues :

uv pip list | grep -i -E "starlette|fastapi|jinja2"npm ls vite

Règles que Nexy suit

Ne faites jamais confiance à l'en-tête Host pour les chemins. Nexy lit scope["path"], et non request.url.path, dans son propre middleware (middleware d'annuaire). Faites de même dans le vôtre.
Échappez ce qui atteint HTML. Les accessoires transmis aux composants clients, les attributs Link, les attributs Image, Audio et Video, les ancres de table des matières et les détails HTTPException sont tous échappés en HTML. Un modèle .nexy ne s'échappe pas tout seul : écrivez {{ value | e }} pour toute valeur provenant d'un visiteur ou de la base de données, et jamais | safe lors d'une saisie utilisateur.
Les points de terminaison du développeur sont uniquement en boucle et étroits. Le point de terminaison de rendu de développement (/__nexy__/render) n'accepte que les fichiers sous src/routes/ avec une extension .tsx ou .jsx, et n'est accessible que via le serveur de développement, qui refuse les en-têtes Host étrangers.
Les détails de l'erreur ne sont pas divulgués. Une page d'erreur qui échoue elle-même affiche uniquement le code d'état.
Les réponses de production comportent des en-têtes sécurisés. X-Content-Type-Options: nosniff et Referrer-Policy: strict-origin-when-cross-origin, à moins que votre code ne définisse les siens. L'en-tête Server n'est pas envoyé. Ajoutez un Strict-Transport-Security et un Content-Security-Policy dans votre proxy ou middleware : ils dépendent de votre domaine.
Un crash affiche une référence, pas l'erreur. Voir Pages d'erreur.
Pas de eval et pas de shell=True dans le code Python de Nexy. Les programmes externes s'exécutent avec une liste d'arguments.

Réaliser les audits

python scripts/audit_dependencies.py        # Python dependencies against the locknpm audit                                    # in a scaffolded projectuv run bandit -r nexy -c .bandit             # static analysis of Nexy itself

Le propre référentiel de Nexy exécute le premier et le troisième lors de ses vérifications. Un nouvel avis sur un étage supérieur est traité en surélevant l'étage dans pyproject.toml ou dans l'échafaudage package.json, puis en régénérant le verrou.

Déployer en toute sécurité

Définissez useTrustedHost sur vos domaines : il rejette les en-têtes Host inattendus avant toute route.
N'exposez pas le serveur de développement Vite : nx dev le maintient en boucle derrière l'origine Nexy.
Définissez useDocs = False si le schéma API ne doit pas être public.

Voir Middleware et sécurité.

Sources

Prochaines étapes

Modifier sur GitHub