Antes de lanzar
tu app.

Inventario de tablas expuestas y de sus políticas, una por operación:

select schemaname, tablename, rowsecurity
from pg_tables
where schemaname in ('public')
order by tablename;

select schemaname, tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname in ('public')
order by tablename, cmd, policyname;

Adapta la lista de esquemas a los que expone tu API. Después repite las pruebas como anónimo y como usuario autenticado para las cuatro operaciones.

Evidencia que acepto: inventario completo, políticas por operación y tests que demuestren lo permitido y lo denegado.

Un UUID impredecible ayuda contra la enumeración, pero no es autorización: si el id se filtra en un listado, en un log o en una URL, el control tiene que seguir en pie.

Repite la prueba con ids obtenidos de listados, logs y URLs, no solo con los que te devuelve tu propia interfaz.

Evidencia que acepto: tests negativos por objeto y operación.

Es mass assignment, hoy dentro de API3:2023. El síntoma clásico es un PATCH que acepta cualquier propiedad que le llegue.

Evidencia que acepto: esquema de entrada explícito y un test que demuestre que una propiedad no autorizada no modifica el registro.

Evidencia que acepto: esquema de respuesta por endpoint y tests que fallen si aparece una propiedad no permitida.

No pegues valores reales en comandos compartidos ni en capturas.

Evidencia que acepto: inventario con tipo, alcance, ubicación, propietario y fecha de rotación.

rg -n "EXPO_PUBLIC_|NEXT_PUBLIC_|VITE_" . \
  -g '!node_modules' -g '!dist' -g '!build'

Clasifica cada resultado: una URL o una clave pensada para ser pública puede estar bien ahí. Si una operación necesita un secreto, lo que se mueve al servidor es la operación, no solo la clave.

Evidencia que acepto: revisión del build final.

git log --all --oneline --decorate
git log --all -S 'NOMBRE_O_FRAGMENTO_NO_SENSIBLE' --oneline

GitHub lo dice en ese orden: revocar o rotar es el primer paso, y una vez hecho, reescribir el historial puede no ser necesario. Si el secreto siguió expuesto en clones, forks o vistas cacheadas, eso ya no lo arregla un rebase.

No publiques el valor mientras lo buscas.

No todos los endpoints llevan login: uno puede ser público a propósito, un webhook verifica una firma, un cron usa un secreto o una identidad de servicio, y un enlace compartido usa un token limitado. Lo que no puede haber es una ruta sin política intencional.

Evidencia que acepto: una matriz de endpoint por actor y acción, con tests negativos automatizados.

En web: cookie con HttpOnly, Secure y el SameSite que corresponda. HttpOnly evita leerla desde JavaScript, pero el navegador la sigue enviando, así que aparece CSRF.

En móvil: Keychain en iOS o Keystore en Android, a través de una abstracción segura, y decidiendo si entra en el backup.

Evidencia que acepto: la ubicación documentada y los tests de ciclo de vida, sin tokens impresos en logs.

OWASP pone Argon2id primero, con parámetros mínimos que conviene revisar cada cierto tiempo, después scrypt, y bcrypt solo para lo heredado, con su límite de 72 bytes.

Si usas un proveedor, lo correcto es precisamente no hashear tú nada.

Un proveedor social puede aplicar sus propios factores, y aun así tu app sigue teniendo que proteger los cambios de identidad y de sesión.

Evidencia que acepto: la política escrita por riesgo y la prueba de que el step-up se aplica de verdad.

Validar no previene XSS por sí solo: eso es el punto 14, y son cosas distintas que se usan juntas.

Evidencia que acepto: el esquema ejecutándose en el límite de confianza y tests negativos.

rg -n "EXECUTE|query\(|raw\(|SELECT .*\$\{|ORDER BY.*\$\{" . \
  -g '!node_modules'

La búsqueda da candidatos, no un veredicto: cada resultado se mira.

Evidencia que acepto: consultas parametrizadas o mapeo explícito de identificadores, más tests de inyección.

Como mapa rápido: texto en HTML va con textContent; un atributo inocuo y fijo, con binding seguro o setAttribute; un parámetro de URL, validando el destino y codificando el parámetro; y el HTML que aceptas a propósito, sanitizado.

En React o React Native el framework ya codifica en la mayoría de sitios. El riesgo real está en dangerouslySetInnerHTML, en innerHTML y en el WebView.

Hay contextos que es mejor no usar aunque sepas codificarlos, como meter datos del usuario dentro de JavaScript en línea.

Bloquea loopback, rangos privados, link-local y los endpoints de metadatos de tu proveedor de nube salvo que tengas una razón explícita.

Normaliza y comprueba todas las direcciones A y AAAA, incluidos IPv4 e IPv6. Evita que la conexión vuelva a resolver el dominio hacia una IP que no hayas validado: usa una implementación preparada para SSRF o conecta contra la dirección validada preservando correctamente Host y SNI. Desactiva las redirecciones automáticas o repite el control completo en cada salto.

Si el caso de uso lo permite, una allowlist de dominios es más fácil de defender que una lista de bloqueos.

OWASP lo dice claro: ninguna técnica basta sola. Valida firma o contenido cuando aplique y escanea archivos de riesgo si tu caso lo pide.

Evidencia que acepto: tests por capa y la comprobación de autorización en la lectura, no solo en la escritura.

Rate limiting no es solo peticiones por IP: una IP puede ser un colegio entero y un atacante puede tener mil. El límite útil combina identidad, sesión, dispositivo, tenant y operación.

Evidencia que acepto: un presupuesto por operación y un test que demuestre el techo.

Cuando el proveedor lo permita, valida también el hostname, la acción y la vigencia del token.

Para quien ya está verificado, respeta el último estado confirmado y el ciclo del proveedor, incluidos los periodos de gracia. Quitar el acceso porque el verificador no contesta es el error contrario.

Evidencia que acepto: idempotencia y una reconciliación posterior.

Las operaciones destructivas, financieras, administrativas o hacia fuera necesitan alcance limitado y, según el riesgo, una confirmación vinculada a la acción exacta. No todo delete necesita un modal.

Evidencia que acepto: autorización en el servidor por acción y recurso, tokens de aprobación de vida corta, idempotencia y traza.

Lo que sí es un fallo de esta capa es exponer sin querer un endpoint, un bucket, un panel, una ruta de depuración o un archivo. Un recurso puede ser público a propósito; el problema es el que lo es por descuido.

Revisa buckets y rutas públicas por inventario, no de memoria.

curl -sS -D - -o /dev/null https://TU-DOMINIO-DE-STAGING.example

OWASP recomienda no poner X-XSS-Protection o ponerla a 0, y marca Expect-CT y Public-Key-Pins como obsoletas.

Una API que solo devuelve JSON no saca el mismo partido a todas las cabeceras que una página interactiva. Y HSTS solo se valida sobre HTTPS: piensa antes de meter includeSubDomains.

Mira también las diferencias sutiles: un mensaje distinto para "ese email no existe" y para "contraseña incorrecta" es un enumerador de cuentas.

No registres contraseñas, tokens, claves ni datos personales que no necesites.

Un informe semanal no cuenta como alerta. Y una alerta sin un runbook al lado llega a alguien que no sabe qué hacer con ella.

25A · Mide RPO y RTO, comprueba integridad y anota qué sistemas no entran en el backup principal: objetos, secretos, proveedores externos. No sobrescribas producción para probarlo.

25B · Documenta cuándo desaparecen los datos de los backups y cómo evitas reintroducir lo borrado si algún día restauras. El derecho de supresión tiene excepciones: no significa borrar cualquier dato en cualquier circunstancia.

Evidencia que acepto: fecha, backup usado, entorno, duración, checks ejecutados y limpieza posterior.