Checklist de seguridad para código generado por IA en Laravel
Hola, bienvenido. En esta lección vamos a juntar en una lista de revisión todo lo que hemos corregido en esta sección, del paquete inventado a la clave en el repositorio. La vamos a guardar en el proyecto, en docs/ai-code-review-checklist.md, y se la vamos a dar al agente con un AGENTS.md, el archivo de instrucciones que leen Claude Code, Codex, Cursor y Copilot. Así el agente la aplica a su propio trabajo antes de entregártelo, y tú la tienes a mano cuando lo revisas.
¿Para qué una lista, si ya tenemos los tests de seguridad? Porque los tests vigilan lo que ya hemos corregido. Si mañana le pides al agente una pantalla de pagos, el controlador nuevo no tiene ningún test que compruebe que llama a la policy. En la lección 1 vimos por qué eso pasa la revisión: al revisar leemos para confirmar que el código hace lo que pedimos, y es fácil no preguntarse qué debería impedir. La lista es justo esa pregunta, escrita de antemano.
Las reglas de la sección
Cada lección de la sección ha dejado una regla. Juntas quedan así:
| Lección | Lo que traía invoices |
La regla |
|---|---|---|
| 5 | Un paquete de Composer que no existe | Comprobar cada paquete en Packagist antes de instalarlo |
| 6 | show y la descarga sin llamar a la policy |
Cada acción que recibe un modelo por la URL comprueba que es del usuario |
| 7 | $guarded = [] y $request->all() al editar |
$fillable, un form request y validated() |
| 8 | Un whereRaw con el texto del usuario y unas notas con {!! !!} |
El texto del usuario va como binding y se escapa antes de pintarlo |
| 9 | La clave del servicio de PDF en config/services.php |
env() sin valor por defecto y .env.example vacío |
En la lista las ordenamos en los 2 grupos que vimos en la lección 1: las comprobaciones que no están y el código que falla en un detalle. ¿Por qué agruparlas así? Porque cada grupo se revisa de una forma distinta. Las comprobaciones que no están no se encuentran buscando nada, porque no hay nada que buscar: se encuentran leyendo cada acción nueva y preguntándote qué debería impedir. El código que falla en un detalle, en cambio, deja un rastro concreto, como un whereRaw, un {!! o un composer require, y ese rastro se puede buscar. Por ejemplo, desde la raíz del proyecto:
La búsqueda solo encuentra la línea de las notas, y al leerla ves que el contenido pasa por e() antes de pintarse, así que está bien. Fíjate en el reparto: el comando encuentra los candidatos y la decisión la toma quien revisa. Sobre el diff de un agente, la misma búsqueda te dice en segundos si hay algo de este grupo que mirar con calma.
- 02La checklist en el proyecto
- 03Qué revisa composer qa y qué revisa una persona
- 04AGENTS.md: la lista para cualquier agente
