Antes de publicar tu web hecha con IA: los 20 chequeos de seguridad

Una lista de 20 comprobaciones que hay que hacerle a una web o una app antes de publicarla, pensada para quien la ha montado con ayuda de una IA. La gracia es que la IA puede revisarlas ella misma: le pegas la petición de esta ficha y te dice, punto por punto, cómo está cada cosa.

Estos son los veinte puntos:

Y hay tres más que a estas listas se les suelen olvidar:

• Si has hecho una web o una app con IA y estás a punto de publicarla.
• Si tu web ya está en marcha y nunca le has pasado una revisión.
• Si trabajas para clientes: es una buena lista para entregar un trabajo con la conciencia tranquila.
• Para revisar tu propio proyecto antes de meterle datos de verdad (usuarios, pagos, correos).

No hace falta que sepas programar: le pasas esta petición a la IA y ella mira el código. Tú solo tienes que hacer las preguntas y no dar por buenas las respuestas.

• Abre el proyecto en la IA que uses (la que lo construyó, si puede ser).
• Pega esto tal cual:

Vas a revisar la seguridad de este proyecto antes
 de publicarlo. No cambies nada todavía: primero
 revisa y dime qué encuentras.

Repasa estos 23 puntos, uno a uno. Para cada uno
 dime: (a) cómo está ahora, (b) el riesgo, y
 (c) el cambio concreto que propones.

1. Claves y contraseñas: ¿están fuera del código?
2. Variables de entorno: ¿lo sensible se lee de
   un .env, con un .env.example sin valores reales?
3. Historial de git: busca claves filtradas
   (sk-, AIza, tokens) en TODO el historial.
4. Rutas de administrador: ¿están protegidas?
5. Autenticación: ¿quién entra y cómo se guardan
   las contraseñas?
6. Permisos: ¿cada usuario ve solo lo suyo?
   Busca dónde cambiando un id en la dirección
   se vean datos de otro.
7. Entradas: ¿se validan y limpian todos los
   datos que llegan?
8. XSS: ¿se escapa todo lo que se muestra?
9. Base de datos: ¿todas las consultas usan
   parámetros? Señala cualquier SQL concatenado.
10. Reglas de la base de datos y permisos de acceso.
11. Límite de peticiones en las rutas sensibles.
12. Tope de gasto en las claves de pago
    (IA, mapas, correo).
13. Subida de archivos: tipos, tamaño, dónde se
    guardan y que no se puedan ejecutar.
14. CSRF: ¿los formularios lo llevan y se
    comprueba en el servidor?
15. CORS: nada de «*» con credenciales.
16. HTTPS: redirección, certificado y HSTS.
17. Cabeceras: HSTS, CSP, X-Content-Type-Options,
    X-Frame-Options, Referrer-Policy.
18. Cookies: Secure, HttpOnly y SameSite.
19. Modo prueba apagado y sin mensajes de error
    internos a la vista.
20. Producción: cachés activadas y logs fuera
    de la carpeta pública.
21. Librerías actualizadas y sin fallos conocidos
    (composer audit, npm audit).
22. Registros: ¿te enterarías si alguien entra?
23. Copias de seguridad: ¿existen y se han
    probado alguna vez?

Al terminar:
- Dame una tabla con los 23 y un semáforo
  (bien / revisar / mal).
- Lo que esté mal, arréglalo empezando por lo
  que se ve desde fuera.
- No digas que algo está bien si no lo has
  comprobado en el código: escribe SIN COMPROBAR.

• Lee la tabla que te devuelva y arrega lo que esté en rojo, de lo que ve el público hacia dentro.
• Pídele que te lo deje por escrito: un fichero SEGURIDAD.md con lo que estaba mal y lo que hizo. Dentro de seis meses no te acordarás.
• Cuando esté arreglado, pásale la lista otra vez: es la única forma de saber si de verdad se corrigió.

• No te fíes de un «todo bien». Las IA dicen que sí con mucha facilidad. Si te dice que algo está bien, pregúntale dónde lo ha comprobado y que te enseñe el fichero y la línea. Si no puede, es SIN COMPROBAR.
• Lo del historial de git (punto 3) es lo que más duele. Aunque borres una clave hoy, sigue en los commits de antes. Si alguna vez has tenido una clave en el código, cámbiala: borrarla no basta.
• El tope de gasto (punto 12) no lo arregla la IA. Eso se configura en la web del servicio (OpenAI, Google y demás). Entra en su panel y pon un límite: una clave filtrada sin tope puede costarte una factura de susto.
• No revises atacando. Que la web esté en producción significa que está atendiendo a gente: no le mandes pruebas de inyección para «ver si salta». Eso se prueba primero en tu copia local.
• Los 20 puntos cubren lo básico, no todo. No entra aquí el fraude, el spam en formularios, las normas de protección de datos ni quién tiene acceso al servidor. Si tu web guarda datos de personas, eso es otra faena aparte.
• Y las copias. Una copia que nunca se ha probado no es una copia: es una esperanza. Restaura una en un sitio aparte y comprueba que abre.

Dos cosas buenas de esta lista, para ser justos: es de las pocas que aparecen por ahí que da el contenido entero en vez de mandarlo por privado, y el punto 3 (el historial de git) es de los que casi nadie menciona.

1. La IA no puede leer tu proyecto. Dale los ficheros (o el repositorio) y dile dónde está cada cosa: app/, routes/, public/, .env.

2. Te dice que todo está bien en dos líneas. Es que no se lo ha mirado. Pídele: «enseñame el fichero y la línea de cada punto, y escribe SIN COMPROBAR en los que no hayas podido mirar».

3. Te propone cambiar medio proyecto. Ve por partes y pídele una cosa cada vez, empezando por lo que se ve desde fuera. Nunca lo arregles todo de golpe en producción.

4. Rompes algo al arreglarlo. Por eso lo primero es tener la copia de seguridad hecha y probada, y trabajar en tu ordenador antes de subirlo.

5. No entiendes el punto 15 (CORS). Es una regla que dice quién puede llamar a tu aplicación desde otro sitio. Si no la tocas y usas la configuración de serie, ya está bien; solo hay que preocuparse si alguien la ha abierto con un comodín.

6. No tienes ni idea de por dónde empezar. Empieza por el 1, 16, 18 y 19: son los que cualquiera puede aprovechar desde fuera y los que se arreglan en un rato.