Ciberseguridad · Desarrollo

OWASP: más de 15 años aprendiendo que la seguridad debe comenzar en el código

28 oct 2026 · 11 min de lectura · Infraestructura · José Areche

En 2011, en el OWASP Latin America Tour en Lima (ISIL), escuché con claridad una idea que todavía me acompaña: la seguridad de una aplicación no es un parche al final; empieza en el código y en las decisiones de diseño.

Desde entonces el stack cambió: de PHP y servidores propios a APIs, multi-tenant, contenedores, CDN, WAF y ahora también código sugerido por IA. Lo que no cambió es la regla de oro: que un sistema funcione no significa que sea seguro.

Esta nota resume qué es OWASP hoy, el Top 10:2025, cómo lo aplico en el día a día (plataformas de comunicaciones y software propio), cómo activar reglas OWASP en Cloudflare, un manual PDF gratuito para aprender a probar y una herramienta Python educativa para revisar un proyecto sin ser intrusivo.

00 / ANTESAntes de OWASP: curiosidad, tiempo libre y una internet distinta

Antes de conocer OWASP —y antes incluso de pisar un instituto de informática— yo era joven, tenía mucho tiempo libre y una curiosidad bastante concreta: qué estaba expuesto en internet en aquella época.

No hablo de un laboratorio ordenado. Hablo de lo que entonces se veía a simple vista o con poca resistencia: recursos compartidos mal cerrados, paneles de administración, servidores FTP, sistemas de aprovisionamiento y un montón de cosas que alguien había dejado al alcance sin pensarlo demasiado. El desconocimiento de muchos administradores era real; mi curiosidad también.

En ese mundo, a veces «desfacear» una web se sentía casi como un concurso entre curiosos y grupos de otros países. No era por dinero. Era hobby del tipo «lo hago porque puedo». No sabíamos —o no queríamos ver— que más adelante eso tendría costo real, consecuencias y un nombre distinto al de juego.

Siempre intenté quedarme del lado que yo consideraba ético: mirar, observar, documentar y, a veces, avisar. Escribí de forma anónima a varias universidades y entidades públicas. Casi nunca hacían caso. Seguía habiendo acceso a sitios que no deberían estar así: diarios «chicha», hasta entornos ligados a medios más grandes como El Comercio, empresas distribuidoras… En fin: era joven, y más allá de mirar y avisar, no había mucho más que pudiera (o debiera) hacer.

Luego entré a un instituto de informática. Digamos que tampoco fue la gran cosa: más aburrido de lo que esperaba, pero había que ir. Aguanté un tiempo y después aprendí más por mi cuenta. Aquella etapa —la curiosidad, lo que se veía expuesto, el hábito de documentar y el roce con gente que sí administraba sistemas— hoy me ayuda a complementar el día a día: no para repetir aquella lógica, sino para entender por qué la seguridad tiene que empezar antes de que algo quede en internet.

OWASP, cuando llegó, me dio palabras y un marco para lo que ya venía oliendo: que funcionar no es lo mismo que ser seguro, y que la responsabilidad importa más que la demostración.

01 / RECUERDOOWASP Latin America Tour 2011 (y un regreso en 2019)

Estas fotos son de aquella edición en Lima. No son stock: son del evento al que asistí.

En 2019 volví a un OWASP LATAM Tour en Lima. Conservo la entrada de Eventbrite a mi nombre; la dejo aquí solo como recuerdo personal del evento (11 may 2019, UPC Monterrico), sin inventar detalles de la agenda.

02 / QUÉ ESOWASP y el Top 10:2025

OWASP (Open Worldwide Application Security Project) es una comunidad abierta que publica guías, estándares y el famoso OWASP Top 10: un consenso amplio sobre los riesgos más críticos en aplicaciones web. No soy parte de la Fundación OWASP; uso su material como referencia práctica, igual que miles de equipos.

La edición 2025 (listado oficial en español) es:

1. A01:2025 — Pérdida de Control de Acceso
2. A02:2025 — Configuración de Seguridad Incorrecta
3. A03:2025 — Fallas en la Cadena de Suministro de Software
4. A04:2025 — Fallas Criptográficas
5. A05:2025 — Inyección
6. A06:2025 — Diseño Inseguro
7. A07:2025 — Fallas de Autenticación
8. A08:2025 — Fallas en la Integridad del Software o de los Datos
9. A09:2025 — Fallas en el Registro, Alerta y Monitoreo de Seguridad
10. A10:2025 — Manejo Inadecuado de Condiciones Excepcionales

Fuente: OWASP Top 10:2025 (es).

03 / LECCIONESSeguridad dentro del ciclo de desarrollo

Lo que aprendí con los años —y lo que intento aplicar en proyectos como plataformas de telefonía/comunicaciones multi-tenant y APIs propias— no es un checklist mágico; es disciplina:

• Control de acceso desde el diseño: un tenant no puede ver ni tocar lo de otro. Los IDs en la URL no son permiso.
• Autenticación y sesiones con criterio: tokens cortos, rotación, cierre de sesión real, menos «confiar en que el front ya filtró».
• APIs como superficie pública: validar entrada, limitar tasa, no filtrar stack traces ni secretos en errores.
• Configuración: debug apagado en producción, secretos fuera del repo, TLS verificado de verdad.
• Registro y alerta: si nadie mira los logs de auth fallida o de denegaciones, A09 te está esperando.

Ningún ejemplo de esta nota incluye IPs, credenciales ni datos de clientes. El punto es el hábito, no el inventario ajeno.

04 / DEUDALa deuda tecnológica también es deuda de seguridad

Un legacy sin soporte no solo «es viejo»: es superficie que ya nadie parchea. Por eso en PortalPBX hablamos de modernización progresiva —parchear lo que tiene soporte, aislar lo vulnerable, migrar a Go (u otra tecnología adecuada) lo expuesto a internet— sin apagar el negocio. Lo conté con más detalle en Deuda tecnológica heredada y en el aviso de PHP2Shell.

OWASP encaja ahí: te da un lenguaje común para priorizar qué duele primero (acceso, config, inyección, auth) mientras migras por etapas.

05 / BENEFICIOSPor qué vale la pena aplicarlo

1. Lenguaje compartido entre desarrollo, operaciones y negocio.
2. Prioridad clara: no todo el backlog de seguridad pesa igual.
3. Menos sorpresas en producción: muchas fallas del Top 10 son evitables en code review.
4. Mejor conversación con proveedores y clientes cuando piden «cumplir OWASP».
5. Base para WAF y pruebas: sabes qué estás mitigando y qué aún debes corregir en código.
6. Cultura: la seguridad deja de ser un evento anual y pasa a ser parte del SDLC.

06 / CLOUDFLAREOWASP Core Ruleset (y lo que no hace)

Si tu sitio o API pasa por Cloudflare, puedes activar el Cloudflare OWASP Core Ruleset (su implementación del OWASP ModSecurity CRS):

1. En el panel: Security → Settings (o el flujo actual de Security rules).
2. Filtra por Web application exploits si te ayuda a encontrarlo.
3. Activa OWASP Core Ruleset y guarda.
4. Revisa paranoia level (PL1–PL4), umbral de score y acción (log / challenge / block). Empieza conservador y ajusta mirando falsos positivos.

Documentación: Cloudflare OWASP Core Ruleset · configurar en el dashboard.

Importante: un WAF no convierte una app insegura en segura. Bloquea patrones y compra tiempo; el control de acceso, la auth y el diseño siguen siendo tuyos.

07 / HERRAMIENTAOWASP Project Audit (Python educativo)

Armé un script pequeño, solo con la biblioteca estándar de Python 3.10+, para recordatorios no intrusivos antes de un deploy o un code review:

• Credenciales o secretos embebidos
• SQL sospechoso / concatenado
• Flags de debug encendidos
• Verificación TLS desactivada
• Funciones peligrosas (eval, exec, pickle.loads, etc.)
• Cabeceras HTTP de seguridad ausentes (si pasas --url)

# Revisar un directorio de proyecto
python3 owasp_project_audit.py --path ./mi-proyecto

# Revisar cabeceras de una URL pública
python3 owasp_project_audit.py --url https://ejemplo.com

# Ambos + salida JSON (útil en CI suave)
python3 owasp_project_audit.py --path ./mi-proyecto --url https://ejemplo.com --json

Descarga: owasp_project_audit.py — uso educativo. No es un pentest ni sustituye SCA, SAST comercial o una revisión humana.

08 / MANUALWSTG y otros recursos

Para aprender a probar aplicaciones web con método, el OWASP Web Security Testing Guide (WSTG) es de lo mejor que hay, y es gratuito:

• WSTG v4.2 (PDF)
• OWASP Top 10:2025
• ASVS (qué verificar según el nivel de rigor)
• Cheat Sheet Series

09 / PARA EMPEZARSi estás empezando (y si usas IA para codear)

1. Lee el Top 10:2025 completo una vez, sin prisa.
2. Elige un riesgo (por ejemplo A01 o A05) y revísalo en tu proyecto esta semana.
3. Activa logging de auth y de denegaciones; míralo de verdad.
4. Si usas Cloudflare, enciende reglas en modo log antes de bloquear.
5. Corre el script de arriba como recordatorio, no como certificado de «ya estamos bien».

Y un aviso de esta época: el código que genera una IA también puede traer A02, A05 y A07. Pedir «hazme el endpoint» sin pedir validación, authz y manejo de errores es fabricar deuda de seguridad a velocidad de autocompletado. Revisa igual —o más— que si lo hubieras escrito a mano.

10 / CIERRELa referencia sigue siendo útil

Desde aquel Tour en 2011 hasta 2026, OWASP me ha servido menos como dogma y más como brújula: priorizar, nombrar el riesgo y meter la seguridad en el ciclo de desarrollo.

Si quieres conversar sobre cómo aterrizar esto en un legacy, en una API multi-tenant o en un WAF sin romper producción, escríbeme por el contacto de joseareche.com.

Aviso: esta publicación es educativa y refleja experiencia personal aplicando material público de OWASP y documentación de terceros (Cloudflare, etc.). No representa a la OWASP Foundation ni sustituye una auditoría profesional, un pentest o asesoría legal/de cumplimiento.