# Auditoría de seguridad y accesibilidad

Equipo: ... · Fecha: ... · Commit auditado: ...

Copien este archivo a `docs/auditoria.md` en su repositorio y llénenlo mientras
hacen el laboratorio de la [semana 15](../../weeks/week-15.md). Sirve también
para `docs/seguridad.md` de P5: las categorías y los estados son los mismos.

**Reglas.** Las pruebas de ataque se hacen solo contra su propia copia, nunca
contra un sistema que no es suyo. Escriban los comandos exactos y peguen la
respuesta real: un hallazgo que otra persona no puede reproducir no sirve.

## Cómo llenar un hallazgo

Cada hallazgo es una fila de la tabla de la sección 9 y, si hace falta detalle,
una subsección. Tiene estos campos:

- **Qué es:** el problema en una frase, y quién resulta perjudicado.
- **Cómo se reproduce:** los comandos exactos y la respuesta que obtuvieron.
- **Categoría:** de OWASP (`A01:2025 Broken Access Control`, `A05:2025 Injection`,
  ...) o un criterio de WCAG (`WCAG 2.1.1 Teclado`).
- **Severidad:** según la escala de abajo, con una frase que la justifique.
- **Corrección propuesta:** el cambio mínimo, y cómo se comprobaría.

| Severidad | Qué significa |
|---|---|
| Crítica | Cualquiera, sin cuenta ni conocimientos especiales, lee o cambia datos de otras personas, o deja el servicio caído. |
| Alta | Hace falta algo más (que la víctima abra una página, conocer un dato) y el daño es el mismo; o una persona no puede completar la tarea principal. |
| Media | El daño es limitado, o las condiciones para que ocurra son poco probables; o la tarea se puede hacer con mucha dificultad. |
| Baja | Mejora una defensa que no es la principal, o molesta sin impedir nada. |

## 1. Modelo de amenazas

**Qué estamos construyendo.**

Activos (lo que hay que proteger, y qué propiedad importa: confidencialidad,
integridad, disponibilidad):

| Activo | Dónde vive | Propiedad que más importa | Por qué |
|---|---|---|---|
| | | | |

Actores (quién usa o ataca el sistema, y qué debería poder hacer):

| Actor | Qué debería poder hacer | Qué no debería poder hacer |
|---|---|---|
| | | |

Puntos de entrada (una fila por cada ruta de la API, y la página):

| Método y ruta | Qué datos devuelve o modifica | Quién debería poder llamarla | Quién puede hoy |
|---|---|---|---|
| | | | |

Dónde está la frontera de confianza (qué lado controlan ustedes y qué lado no):

**Qué puede salir mal.** Para cada entrada, qué pasa si quien llama miente.

**Qué vamos a hacer al respecto.** Sale de la sección 9.

**Lo hicimos bien.** Qué prueba o procedimiento lo demuestra:

## 2. Control de acceso

Cada intento con su comando y su respuesta.

```sh
D=$(TZ=America/Lima date -d '+2 days' +%F)
```

| Lo que intentamos | Comando | Respuesta | Qué debería pasar |
|---|---|---|---|
| | | | |

## 3. XSS

Por dónde llega a la página un texto que escribe un usuario (archivo y línea de
cada lugar):

Con `<b>prueba</b>`, lo que se vio:

Con `<img src=x onerror=alert(1)>`, lo que se vio:

Corrección, en la rama: ...

La prueba o el procedimiento manual que demuestra que el nombre se muestra como
texto:

1.
2.

## 4. Datos personales y Ley 29733

*Esto es un ejercicio de curso, no asesoría legal. Lo que decidan aquí no
reemplaza la opinión de un abogado ni la de la Autoridad Nacional de Protección
de Datos Personales.*

Citen el artículo que usan: Ley N.° 29733 y su reglamento (Decreto Supremo
N.° 016-2024-JUS). Lo que no sepan cómo resolver, anótenlo como pregunta para
el cliente.

| Dato personal | Dónde se guarda | Por dónde sale (rutas, página, logs) | Finalidad | Quién lo necesita ver | ¿La respuesta actual es proporcional? (art. 7) | Cuándo se borra |
|---|---|---|---|---|---|---|
| | | | | | | |

Cambios mínimos que proponen para cumplir finalidad (art. 6) y proporcionalidad
(art. 7):

Preguntas para el cliente:

## 5. Cabeceras

```sh
curl -s -D - -o /dev/null localhost:3000/
```

| Cabecera | Antes | Después | Por qué ese valor |
|---|---|---|---|
| Content-Security-Policy | | | |
| X-Content-Type-Options | | | |
| Referrer-Policy | | | |

Lo que muestra la consola del navegador con la CSP puesta (una violación se ve
distinta de un 404):

## 6. Accesibilidad

**Con el teclado.** Una reserva completa con Tab, Shift+Tab, Enter y Espacio.
Dónde se trabaron:

**Lighthouse.** Versión, puntaje y qué avisó. Qué problema de los que encontraron
con el teclado **no** avisó:

**Contraste.** Una fila por cada combinación de `public/styles.css`.

| Selector | Texto | Fondo | Razón | Mínimo (1.4.3) | ¿Cumple? |
|---|---|---|---|---|---|
| | | | | | |

**Información que solo se transmite con color:**

**Lector de pantalla** (NVDA, VoiceOver, si pudieron). ¿Se anuncia el resultado
de una reserva?

## 7. Licencias

```sh
jq -r '.packages | to_entries[] | select(.key != "") | .value.license' package-lock.json | sort | uniq -c | sort -rn
```

Resultado:

¿Alguna obliga a algo más que conservar el aviso?

Qué licencia le pondrían a Kallpa y por qué:

## 8. OWASP Top 10:2025

| Categoría | Qué miramos en nuestra app | Estado | Evidencia o pendiente |
|---|---|---|---|
| A01:2025 Broken Access Control | | | |
| A02:2025 Security Misconfiguration | | | |
| A03:2025 Software Supply Chain Failures | | | |
| A04:2025 Cryptographic Failures | | | |
| A05:2025 Injection | | | |
| A06:2025 Insecure Design | | | |
| A07:2025 Authentication Failures | | | |
| A08:2025 Software or Data Integrity Failures | | | |
| A09:2025 Security Logging and Alerting Failures | | | |
| A10:2025 Mishandling of Exceptional Conditions | | | |

Estados: `Cumple`, `Parcial` (qué falta y por qué se acepta por ahora), `No cumple`
o `No aplica` (con la justificación).

## 9. Hallazgos, de más grave a menos grave

| # | Qué es | Cómo se reproduce | Categoría | Severidad | Corrección propuesta | Pull request o issue |
|---|---|---|---|---|---|---|
| 1 | | | | | | |
| 2 | | | | | | |

Corrijan los dos más graves en pull requests separados, con revisión. El resto
queda como issues, enlazados desde esta tabla.