Seguridad web y OWASP Top 10 (nivel conceptual)

Las aplicaciones web (tiendas online, portales de clientes, sistemas internos) son la cara visible de casi cualquier negocio, y por eso un blanco frecuente. El proyecto OWASP publica el Top 10, una lista de las categorías de riesgo más importantes para las aplicaciones web que se usa en todo el mundo como punto de partida para desarrolladores, auditores y dueños de negocios. Esta lección es conceptual y defensiva: aprenderás qué significa cada categoría y cómo se previene. Probar la seguridad de un sitio ajeno sin autorización por escrito es ilegal; los ejemplos se describen para que revises y protejas tus propias aplicaciones.

1. Cómo funciona la web
2. El Top 10 de 2025
3. Cuatro riesgos a fondo
4. Tu tienda online
5. Desarrollo seguro

Cómo funciona una aplicación web en 1 minuto

Tu navegador (el cliente) envía una solicitud HTTP a un servidor: "dame la página del pedido 1045". El servidor ejecuta el código de la aplicación, consulta la base de datos y devuelve una respuesta. Para recordar quién eres entre una página y otra, usa una sesión, normalmente guardada en una cookie. Casi todos los problemas de seguridad web aparecen cuando el servidor confía demasiado en lo que le envía el cliente: un número de pedido, un texto en un formulario o un archivo subido. La regla de oro del desarrollo seguro es: todo lo que viene del usuario se valida en el servidor.

El OWASP Top 10 en su edición 2025

OWASP es una fundación sin fines de lucro dedicada a la seguridad del software. Su Top 10 no es una norma obligatoria, sino un documento de concienciación basado en datos de miles de aplicaciones y en encuestas a la comunidad. Esta es la lista vigente:

Qué cambió frente a la edición 2021

• Nuevas: A03, que amplía la antigua categoría de componentes vulnerables y desactualizados a todo el ecosistema de software, y A10, sobre el manejo de condiciones excepcionales.
• Fusionada: la falsificación de solicitudes del lado del servidor (SSRF) pasó a formar parte de A01.
• Movimientos: la configuración incorrecta subió del quinto al segundo puesto; las fallas criptográficas bajaron del segundo al cuarto; la inyección, del tercero al quinto; el diseño inseguro, del cuarto al sexto.
• Renombradas: A07 (antes "fallas de identificación y autenticación") y A09 (antes "fallas de registro y monitoreo").

Cuatro riesgos a fondo

Control de acceso roto (A01)

Una clienta de una tienda online entra a "Mis pedidos" y la dirección muestra /pedidos/1045. Si el servidor solo comprueba que ella inició sesión, pero no que el pedido 1045 sea suyo, otra persona con sesión iniciada podría ver datos que no le pertenecen. La protección no está en esconder el número, sino en que el servidor verifique en cada solicitud que ese usuario tiene permiso sobre ese recurso. Lo mismo vale para funciones de administrador: ocultar un botón en la pantalla no impide que alguien envíe la solicitud.

Inyección (A05)

La inyección ocurre cuando una aplicación mezcla datos del usuario con instrucciones para la base de datos u otro sistema, y estos terminan interpretando los datos como órdenes. La defensa principal es separar siempre datos e instrucciones con consultas parametrizadas: la instrucción se escribe fija, con marcadores, y los datos se pasan aparte. Así se ve una consulta segura en Python:

import sqlite3

conexion = sqlite3.connect("tienda.db")
correo = input("Correo del cliente: ")

# Correcto: la consulta es fija y el dato viaja aparte (marcador ?)
cursor = conexion.execute(
    "SELECT id, nombre FROM clientes WHERE correo = ?",
    (correo,)
)
print(cursor.fetchall())

La base de datos trata lo que escribió el usuario siempre como un dato, nunca como parte de la instrucción, sin importar qué contenga. Si estás aprendiendo SQL con Python, revisa la lección de bases de datos con Python y SQLite.

Configuración de seguridad incorrecta (A02)

Subió al segundo lugar porque cada vez más de la seguridad depende de configurar bien: servidores, paneles, almacenamiento en la nube y cabeceras HTTP. Revisa que no queden cuentas con contraseñas por defecto, que los mensajes de error no muestren detalles técnicos internos, que no estén activas funciones de prueba y que el servidor envíe cabeceras de seguridad como estas:

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

La primera obliga al navegador a usar siempre HTTPS con tu sitio; la segunda limita desde dónde se pueden cargar scripts y otros recursos; la tercera impide que el navegador "adivine" el tipo de un archivo; la cuarta controla qué información se envía al seguir enlaces. La política de contenido (CSP) debe ajustarse a cada sitio y probarse antes de aplicarla.

Cadena de suministro de software (A03)

Una aplicación moderna puede depender de cientos de librerías y plugins escritos por terceros. Si uno de ellos tiene una falla o es comprometido, tu aplicación hereda el problema. La defensa: mantener un inventario de componentes (a menudo llamado SBOM, lista de materiales del software), instalar solo desde fuentes oficiales, eliminar lo que no se usa, actualizar con regularidad y vigilar los avisos de seguridad de lo que usas.

Si tienes una tienda online o un sitio con gestor de contenidos

No necesitas programar para aplicar lo esencial. Esta lista cubre gran parte del Top 10 para sitios en plataformas como WordPress con WooCommerce o tiendas alojadas. Si estás montando tu tienda, complementa con la lección de ecommerce del curso de marketing digital:

• Núcleo, tema y plugins actualizados; borré los plugins y temas que no uso (A03).
• Cada persona tiene su propia cuenta, con el rol mínimo necesario y doble factor en las de administrador (A01, A07).
• Todo el sitio funciona con HTTPS y redirige desde HTTP (A04).
• No guardo datos de tarjetas: los pagos los procesa una pasarela certificada (A04).
• Tengo copias automáticas del sitio y de la base de datos, y probé restaurarlas.
• Uso un firewall de aplicación web (WAF) del hosting o de un servicio externo.
• Recibo alertas de inicios de sesión de administrador y de cambios en archivos (A09).

Caso: revisión de seguridad de una tienda en Medellín

Seguridad en todo el ciclo de desarrollo

Corregir una falla de diseño cuando la aplicación ya está en producción cuesta mucho más que evitarla en la pizarra. Por eso la seguridad se integra en cada etapa:

1. DiseñoModelado de amenazasPreguntarse "¿qué podría salir mal?" y escribir casos de abuso junto a los casos de uso (A06).
2. DesarrolloBuenas prácticas y revisión de códigoConsultas parametrizadas, validación en el servidor, manejo de errores seguro y revisión entre pares.
3. PruebasHerramientas automáticasAnálisis estático del código (SAST), análisis de componentes de terceros (SCA) y pruebas dinámicas (DAST) en un entorno de pruebas.
4. ProducciónMonitoreo y canal de reporteRegistros y alertas (A09), pruebas de penetración autorizadas y una política para que investigadores reporten fallas de forma responsable.

Errores comunes

Resumen

• La mayoría de las fallas web nacen de confiar en lo que envía el usuario: todo se valida en el servidor.
• El OWASP Top 10:2025 lo encabeza el control de acceso roto, seguido de la configuración incorrecta y la nueva categoría de cadena de suministro.
• Las consultas parametrizadas previenen la inyección; las cabeceras de seguridad y una configuración endurecida reducen A02.
• En una tienda online: actualizaciones, cuentas con rol mínimo y doble factor, HTTPS, pasarela de pago, copias, WAF y alertas.
• La seguridad se integra desde el diseño y en todo el ciclo de desarrollo, y solo se prueba con autorización.

En la próxima lección: Gestión de identidades y accesos: mínimo privilegio. Aprenderás a decidir quién accede a qué, a revisar permisos y a gestionar altas, cambios y bajas sin dejar puertas abiertas.