La seguridad en aplicaciones web a medida se construye en dos frentes: controles escritos en el código desde el primer sprint y una revisión periódica que los ponga a prueba. El OWASP Top 10:2025 indica qué fallos aparecen más en aplicaciones de gestión y APIs de servidor, y sirve como checklist. En Codezone la aplicamos en cada proyecto de desarrollo de aplicaciones web seguras en Madrid.
Una aplicación de gestión concentra pedidos, tarifas, datos de clientes y facturas tras un único login. Un fallo de permisos expone a todos tus clientes a la vez y, si hay datos personales, activa la notificación que detallamos en la guía de protección de datos aplicada al desarrollo de software. En el peor caso toca tirar de una copia de seguridad verificada de la aplicación.
Al terminar sabrás qué controles exigir en el código y qué pruebas pedir antes de cada puesta en producción, algo que conviene contrastar con una auditoría de código antes de heredar un software.
Qué es la seguridad en aplicaciones web según OWASP
La seguridad en aplicaciones web es el conjunto de controles de diseño, código, configuración y operación que impiden que un usuario acceda a datos o acciones a los que no tiene derecho. OWASP, la fundación abierta de seguridad de aplicaciones, la ordena en dos referencias: el OWASP Top 10 para priorizar riesgos y el OWASP ASVS para requisitos verificables.
La prevención de ataques en apps móviles cubre el teléfono; aquí tratamos el servidor y la API, donde viven los datos.
Los riesgos del OWASP Top 10:2025 en una aplicación de gestión
El control de acceso roto ocupa el primer puesto del OWASP Top 10:2025: según la ficha A01:2025 Broken Access Control, el 100 % de las aplicaciones analizadas presentaba alguna forma de este fallo. En un software de gestión se ven así:
- A01:2025 Broken Access Control: un comercial cambia el identificador de la URL `/pedidos/1043` y ve el pedido de otro cliente. En APIs se llama BOLA y encabeza el OWASP API Security Top 10 2023 como API1:2023.
- A02:2025 Security Misconfiguration: un entorno de pruebas abierto a internet o un servidor sin cabeceras de seguridad.
- A03:2025 Software Supply Chain Failures: una librería npm comprometida que entra como dependencia de otra dependencia.
- A05:2025 Injection: un filtro de informes que concatena texto del usuario en SQL.
- A07:2025 Authentication Failures: sesiones que no caducan o un panel sin segundo factor. Lo explicado sobre autenticación con tokens en apps móviles vale para una API web.
Controles de seguridad en el desarrollo de aplicaciones web
Los controles que más riesgo eliminan se escriben una vez en el backend y se reutilizan en todos los endpoints:
- Validación en servidor: esquema por endpoint y consultas parametrizadas; la del navegador se puede saltar.
- Control de acceso por objeto: cada consulta filtra por propietario o por empresa, y lo que no es público se deniega por defecto.
- Gestión de secretos: credenciales fuera del repositorio y con rotación prevista. Vale también para las automatizaciones conectadas, como muestran los fallos de seguridad detectados en n8n.
- Dependencias: inventario de componentes (SBOM) con alertas de vulnerabilidades, también indirectas.
- Cabeceras HTTP: `Content-Security-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options` y `Referrer-Policy` fijadas en el servidor.
Revisión y pruebas de seguridad: SAST, DAST y pentest
Las pruebas de seguridad de una aplicación web combinan herramientas automáticas en el pipeline con revisión manual antes de cada hito:
- SAST (análisis estático): en cada pull request revisado antes de fusionar. Detecta inyecciones y secretos en el código; no entiende los permisos del negocio.
- DAST (análisis dinámico): contra preproducción en cada despliegue. Encuentra configuraciones débiles; no sabe qué datos son de cada cliente.
- Pentest manual: antes del lanzamiento y tras cambios en roles; destapa los fallos de acceso por objeto.
Qué pedir a tu proveedor de software en Madrid
Un proveedor serio entrega evidencias de seguridad con cada versión:
- Los requisitos del OWASP ASVS pactados en contrato y la prueba que verifica cada uno.
- El SBOM y el informe de dependencias vulnerables.
- Los resultados de SAST y DAST con plazo de corrección para cada incidencia abierta.
- Registro de eventos de seguridad con alertas, que es lo que cubre la categoría A09:2025.
Si expones un portal privado de clientes con login propio, añade pruebas de aislamiento: cada usuario de prueba intenta leer los datos del otro.
CodeZone Pro Tip: este middleware de Express evita los fallos IDOR/BOLA autorizando cada objeto en la propia consulta.
// Middleware de Express que autoriza cada objeto por propietario (evita IDOR/BOLA)
const { Pool } = require('pg');
const pool = new Pool(); // credenciales desde las variables PG* del entorno, nunca en el código
// Lista cerrada: el nombre de tabla lo fija el desarrollador, jamás la petición
const TABLAS = new Set(['pedidos', 'facturas', 'presupuestos']);
function autorizarObjeto(tabla) {
if (!TABLAS.has(tabla)) throw new Error(`Tabla no permitida: ${tabla}`);
return async (req, res, next) => {
try {
const id = Number.parseInt(req.params.id, 10);
if (!Number.isSafeInteger(id) || id <= 0) return res.status(400).end();
// req.user lo rellena el middleware de autenticación previo.
// El filtro por cliente va en la consulta: si no hay fila, no hay acceso
const { rows } = await pool.query(
`SELECT * FROM ${tabla} WHERE id = $1 AND cliente_id = $2`,
[id, req.user.clienteId]
);
// 404 en lugar de 403: no confirmamos que el recurso exista para otro cliente
if (rows.length === 0) return res.status(404).end();
req.recurso = rows[0];
return next();
} catch (err) {
return next(err); // el manejador global registra el error sin enviar detalles
}
};
}
// Uso: app.get('/api/pedidos/:id', autenticar, autorizarObjeto('pedidos'), (req, res) => res.json(req.recurso));
module.exports = { autorizarObjeto };Con este patrón, revisar el código se reduce a confirmar que toda ruta con identificador usa el middleware. Para el negocio, cambiar un número en la URL deja de exponer la cartera de otro cliente.
El Coste de Descubrir el Fallo en Producción
Un fallo de control de acceso encontrado en un pull request cuesta una línea de código. El mismo fallo encontrado por un tercero en producción se paga en notificaciones a la autoridad y en la confianza de los clientes afectados. La diferencia la marca integrar OWASP en el proceso desde el primer sprint.
Si tu aplicación de gestión no ha pasado nunca una revisión de seguridad o vas a encargar una nueva, cuéntanos tu caso y revisamos contigo el plan de seguridad.
