DocsConvenciones y conceptos

Seguridad

Cómo Nexy mantiene pequeña su propia superficie de ataque, qué versiones requiere y cómo verificar un proyecto.

Versión pisos

Nexy depende de FastAPI, Starlette, Jinja2, Vite y React. Un piso es la versión más baja que permite Nexy; cada uno responde a un aviso publicado.

Paquete	piso	¿Por qué?
`starlette`	1.0.1	CVE-2026-48710 (BadHost): un encabezado `Host` modificado cambia la ruta Starlette informa al middleware, lo que omite la autorización escrita en `request.url.path`. Catalogado como explotado por CISA.
`fastapi`	0.133.0	la primera versión que acepta un Starlette fijo
`jinja2`	3.1.6	escape del sandbox a través del filtro `attr` (CVE-2025-27516)
`vite` (proyectos estructurados)	6.4.3	`server.fs.deny` omitir rutas alternativas de Windows (CVE-2026-53571); la omisión de cadena de consulta anterior (CVE-2026-39364) afecta solo a Vite 7.1-7.3.1 y 8.0.0-8.0.4
`react`, `react-dom`	19.2.5	los avisos de 2026 React se refieren a los paquetes `react-server-dom-*`, que Nexy no utiliza; el piso mantiene la línea parchada

Comprueba tus versiones resueltas:

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

Reglas que sigue Nexy

Nunca confíes en el encabezado del Host para las rutas. Nexy lee scope["path"], no request.url.path, en su propio middleware (middleware de directorio). Haz lo mismo en el tuyo.
Escape de lo que llega a HTML. Los accesorios pasados a los componentes del cliente, Link atributos, Image, Audio y Video atributos, anclajes de tabla de contenido y HTTPException detalles se escapan de HTML. Una plantilla .nexy no escapa por sí sola: escriba {{ value | e }} para cualquier valor que provenga de un visitante o de la base de datos, y nunca | safe en la entrada del usuario.
Los puntos finales de desarrollador son de bucle invertido y estrechos. El punto final de procesamiento de desarrollo (/__nexy__/render) solo acepta archivos bajo src/routes/ con una extensión .tsx o .jsx, y solo se puede acceder a él a través del servidor de desarrollo, que rechaza encabezados Host externos.
Los detalles del error no se filtran. Una página de error que falla muestra solo el código de estado.
Las respuestas de producción llevan encabezados seguros. X-Content-Type-Options: nosniff y Referrer-Policy: strict-origin-when-cross-origin, a menos que su código establezca el suyo propio. El encabezado Server no se envía. Agrega Strict-Transport-Security y un Content-Security-Policy en tu proxy o un middleware: dependen de tu dominio.
Un bloqueo muestra una referencia, no el error. Consulte Páginas de error.
No eval ni shell=True en el código Python de Nexy. Los programas externos se ejecutan con una lista de argumentos.

Ejecución de las auditorías

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

El propio repositorio de Nexy ejecuta el primero y el tercero en sus comprobaciones. Un nuevo aviso en un piso de arriba se maneja elevando el piso en pyproject.toml o en el andamio package.json, luego regenerando la cerradura.

Implementación segura

Establezca useTrustedHost en sus dominios: rechaza encabezados Host inesperados antes de cualquier ruta.
No exponga el servidor de desarrollo Vite: nx dev lo mantiene en bucle detrás del origen Nexy.
Establezca useDocs = False si el esquema de API no debe ser público.

Consulte Middleware y seguridad.

Fuentes

Próximos pasos

Editar en GitHub