Seguridad de aplicaciones web, integrada desde el desarrollo.
Seguridad web integrada en el desarrollo y el mantenimiento de tus aplicaciones: desarrollo seguro con el OWASP Top 10 como referencia, hardening, dependencias vigiladas, protección de datos conforme al RGPD, monitorización con alertas y evidencias que puedes presentar a un cliente o a un auditor.
Capacidades
Un fallo de seguridad
no avisa antes de llegar.
Un fallo en tu aplicación web supone horas de parada, clientes a los que informar y, si hay datos personales, una notificación a la AEPD. La seguridad se integra en el desarrollo desde el primer día, no como una revisión posterior. Esto es lo que incorporamos con tu equipo.
Desarrollo seguro con OWASP Top 10
Tu aplicación se revisa contra las categorías del OWASP Top 10 durante el desarrollo, no una vez terminada. Validamos las entradas en el servidor, parametrizamos las consultas frente a inyección SQL y cuidamos sesiones, autenticación y control de accesos por rol.
Hardening de la aplicación web
Configuramos la aplicación para que no exponga información interna. Cabeceras HTTP, política de contenidos (CSP), HSTS, rate limiting y errores sin datos internos. Los secretos salen del código y pasan a un gestor de secretos.
Certificado SSL y TLS en el alojamiento
Tu certificado se renueva solo. Configuramos en el alojamiento TLS 1.2/1.3 y monitorizamos la caducidad, para que ningún cliente se encuentre un aviso de sitio no seguro.
Vulnerabilidades en dependencias y librerías
Recibes un informe de las librerías con vulnerabilidades conocidas (CVE). Fijamos versiones con lockfiles, auditamos de forma periódica y actuamos dentro de una ventana de respuesta cuando aparece una CVE.
RGPD técnico en la aplicación web
Cada tratamiento de datos queda con su base legal documentada, junto a la política de cookies y el RGPD aplicado en la aplicación. Si manejas datos de salud, cubrimos las exigencias extra que corresponden.
Plan de respuesta ante incidentes
Tienes por escrito qué ocurre si hay un incidente: cómo se detecta, cómo se avisa a tu cliente y cómo se recupera la aplicación. Si hay brecha de datos personales, se notifica a la AEPD en 72 horas.
Informe de hallazgos reproducibles
Recibes un informe donde cada hallazgo trae los pasos para reproducirlo, el riesgo real que supone para tu aplicación y el orden en que conviene corregirlo. No es la salida en bruto de un escáner automático.
Evidencias para tu cliente o tu auditor
Preparamos las evidencias técnicas incluidas en el alcance: cabeceras y TLS verificados, informe de dependencias, procedimiento de incidentes y base legal documentada. Las relacionamos con los requisitos recibidos y señalamos las comprobaciones pendientes.
¿Qué corregir primero
cuando aparecen varios hallazgos?
El informe relaciona cada hallazgo con el componente afectado, la forma de reproducirlo y su impacto. Con tu equipo acordamos el orden de corrección y qué evidencia permitirá comprobar el cierre.
Hallazgos ordenados por riesgo
- Severidad altaEntradas sin validar en el servidorFormulario de altaCorregido
- Severidad altaSesión que no caducaPanel de administraciónPendiente
- Severidad mediaLibrería con vulnerabilidad conocidaDependenciasCorregido
- Severidad mediaCabeceras de seguridad ausentesTodas las páginasCorregido
- Severidad bajaError que muestra información internaFormulario de contactoPendiente
- Pasos para reproducirlo
- Riesgo real
- Orden de corrección
Proceso
Revisamos tu aplicación web
sin tocar producción.
Probar una aplicación directamente en producción pone en riesgo el servicio. Por eso la revisión se hace en un staging que replica producción. Separamos revisión, priorización y corrección, con una ventana de despliegue acordada y comprobación posterior de los cambios.
- 01
Alcance
Dejamos por escrito qué entra en la revisión: qué aplicaciones, dónde están alojadas, qué datos tratan y si hay pagos por medio. Así sabes qué se revisa y qué queda fuera.
- 02
Revisión en staging
Revisamos cabeceras, TLS, dependencias, accesos, configuración de la nube y código contra el OWASP Top 10 en un staging que replica producción, sin tocarla. En producción solo hacemos comprobaciones de lectura: cabeceras, certificado, versiones expuestas.
- 03
Informe de hallazgos
Recibes el informe de hallazgos, cada uno con sus pasos de reproducción y su riesgo. Lo repasamos con tu equipo y acordamos qué se corrige primero.
- 04
Corrección y nueva comprobación
Los cambios de configuración y de versiones se despliegan en una ventana acordada con tu equipo, con vuelta atrás preparada. Después comprobamos que cada hallazgo queda cerrado y te lo confirmamos.
- 05
Mantenimiento
Tu aplicación sigue revisada después de la entrega: auditoría periódica de dependencias, respuesta ante CVE conocida y plan de respuesta ante incidentes siempre al día.
Leer
Del blog.
Ciberseguridad
PHP2Shell: qué hacer si tu web o tu tienda funcionan con PHP
Las vulnerabilidades PHP2Shell están en PHP, no en WordPress ni en PrestaShop: se corrigen en el servidor. Qué ha pasado, qué versiones las corrigen y qué preguntar a tu hosting.
Ciberseguridad
Claves API de IA: una alerta no evita la factura sorpresa
Guardar bien la clave es solo una parte. Aprende a distinguir una alerta de un corte real y comprueba qué frena el gasto, quién recibe el aviso y cómo sigue funcionando tu web.
Ciberseguridad
Tu web funciona, pero ¿está protegida? 7 puntos que deberías revisar
Que una web cargue y reciba consultas no demuestra que esté protegida. Siete puntos para revisar con tu equipo técnico y pedir evidencias de lo que funciona.
¿Qué evidencia responde
a lo que pide tu cliente?
Partimos de su cuestionario o requisito concreto. Relacionamos cada petición con las comprobaciones y documentos disponibles, y señalamos qué necesita una revisión independiente o queda fuera del alcance.
Lo que pide tu cliente · antes y después
Antes
- Cabeceras y TLSSin comprobar
- DependenciasSin informe
- IncidentesSin procedimiento
- Datos personalesBase legal sin documentar
Se prepara a última hora.
Después
Carpeta de evidencias
- Cabeceras y TLSVerificados
- DependenciasInforme al día
- IncidentesProcedimiento escrito
- Datos personalesBase legal documentada
Lista para enseñar.
Preguntas frecuentes.
Alcance de la revisión
de seguridad web.
Qué cubre la seguridad de aplicaciones web que integramos, cómo se presupuesta, quién responde ante un incidente y dónde empieza el pentest o la auditoría independiente.
¿Qué incluye la seguridad de una aplicación web?
Cinco capas que se trabajan juntas. Código: desarrollo seguro revisado contra el OWASP Top 10 (validación de entradas, consultas parametrizadas, autenticación, sesiones y control de accesos por rol). Configuración: hardening con cabeceras HTTP, CSP, HSTS, rate limiting y mensajes de error que no revelan información interna. Transporte: certificado SSL y TLS 1.2/1.3 con renovación automática. Dependencias: lockfiles, auditoría periódica de librerías y respuesta ante CVE conocida. Datos y procedimiento: cifrado, registros de acceso, copias y un plan de respuesta ante incidentes. El resultado es un informe de hallazgos reproducibles y las evidencias que te pidan un cliente o un auditor.¿Cómo sé si mi web es segura o tiene vulnerabilidades?
Hay señales que puedes comprobar sin acceso al código: que el certificado SSL sea válido y el sitio cargue solo por HTTPS, que el gestor de contenidos y sus extensiones estén actualizados y que no queden usuarios administradores antiguos o con contraseñas compartidas. Lo importante no se ve desde fuera: dependencias con CVE conocidas, permisos mal acotados, secretos en el repositorio o validaciones que solo se hacen en el navegador. Para eso revisamos la aplicación en un entorno de staging y te entregamos un informe de hallazgos reproducibles. Si quieres revisarlo tú primero, tienes siete comprobaciones básicas.¿Qué es el desarrollo seguro de software y cómo lo aplicáis?
Es tener en cuenta la seguridad en cada fase del desarrollo en vez de buscar los fallos cuando la aplicación ya está en producción. En la práctica: los requisitos de seguridad y de acceso a datos se definen junto con los funcionales, las entradas se validan en el servidor, las claves y credenciales se guardan en un gestor de secretos y nunca en el código, las dependencias se fijan con lockfiles y se auditan, y cada cambio pasa por staging antes de producción. Usamos el OWASP Top 10, la lista de referencia de los riesgos más frecuentes en aplicaciones web que publica la fundación OWASP, como lista de comprobación en cada entrega.¿Qué diferencia hay entre el hardening del servidor y el de la aplicación web?
El hardening del servidor reduce la superficie del sistema donde corre la aplicación: servicios innecesarios desactivados, puertos cerrados, actualizaciones del sistema y acceso con claves en lugar de contraseñas. El de la aplicación actúa sobre lo que tocan el navegador y el usuario: cabeceras HTTP y política de contenidos (CSP), HSTS, rate limiting en formularios y APIs, mensajes de error sin información interna, sesiones seguras y sin cuentas ni configuraciones por defecto. Se necesitan los dos. En las aplicaciones que alojamos y mantenemos hacemos ambos; si el servidor lo gestiona otro proveedor, nos centramos en la capa de aplicación y te indicamos lo que conviene pedirle.¿Sois una empresa de ciberseguridad?
Somos una empresa de desarrollo en Madrid que integra la seguridad en las aplicaciones que construye y mantiene. No somos una consultora de ciberseguridad: no tenemos un centro de operaciones de seguridad propio, no hacemos pentest y no certificamos ISO 27001 ni ENS. Lo que hacemos es que tu aplicación web llegue a esas revisiones bien construida, endurecida y documentada, y coordinar la parte técnica con la consultora que firme la auditoría cuando la necesites.¿Hacéis pentest o auditorías de seguridad web? ¿Qué ocurre cuando las necesito?
Hacemos la revisión de seguridad de tu aplicación web (hardening, dependencias, revisión del código e informe de hallazgos) dentro del desarrollo y del mantenimiento; lo que no hacemos es pentest ni firmar una auditoría de seguridad independiente. Para un pentest o una auditoría regulatoria (ENS, ISO 27001, SOC 2, requisitos contractuales de tu cliente) trabajamos con consultoras especializadas que firman el informe y coordinamos la parte técnica: preparamos entornos, reproducimos hallazgos, aplicamos remediaciones y volvemos a probar. El hardening previo que construimos por defecto evita que el pentest encuentre lo obvio.Un cliente o un concurso me pide ISO 27001, ENS o NIS2. ¿Qué tiene que ver con mi aplicación?
Son tres marcos distintos. ISO 27001 es una certificación voluntaria de cómo gestiona la seguridad una empresa, y cada vez más clientes grandes la piden a sus proveedores. El ENS (Esquema Nacional de Seguridad) es obligatorio para quien presta servicios tecnológicos a la Administración pública. NIS2 es la directiva europea que obliga a sectores esenciales, como la fabricación de medicamentos, a vigilar la seguridad de sus proveedores, y por eso llega también a pymes que no están obligadas directamente. Las tres se acreditan a nivel de organización ante una entidad certificadora: nosotros no certificamos. Lo que sí depende del software y del alojamiento es buena parte de los controles técnicos que se revisan: control de accesos, registros de actividad, copias, cifrado y proveedores de nube certificados. Eso lo construimos y lo documentamos para que tengas las evidencias cuando te las pidan.¿Cuánto cuesta y por qué no hay precio en la web?
Porque depende del alcance: cuántas aplicaciones hay que revisar, dónde están alojadas, qué datos tratan y si hay pagos por medio. Con esas cuatro respuestas preparamos una propuesta cerrada. Buena parte del trabajo va dentro del desarrollo o del contrato de mantenimiento, no como un proyecto separado.¿Qué aporta la categoría de Ciberseguridad del Kit Digital?
No cubre auditorías ni el hardening de tu aplicación. Cubre dos soluciones del catálogo: "Puesto de Trabajo Seguro" (protección del dispositivo del empleado) y "Servicio de Ciberseguridad Gestionada" (monitorización continua). Hoy el programa no admite solicitudes nuevas (estado del programa); si tienes un bono concedido, te indicamos qué cubre. Más detalle en Kit Digital Ciberseguridad.¿Si la aplicación está en AWS o Azure no está ya protegida?
El proveedor cloud protege su infraestructura: centros de datos, red física, hipervisor. Todo lo que está por encima es responsabilidad tuya: la configuración de los servicios, los accesos, las dependencias y el código de la aplicación. La mayoría de incidentes en cloud vienen de esa capa, no de la infraestructura del proveedor, y es la que revisamos y endurecemos.¿Qué hago si se filtra una clave o credencial de mi aplicación?
Primero revócala donde se emitió (panel del proveedor, base de datos o servicio) y crea otra con permisos acotados; si es de un servicio de pago, establece además un límite de gasto. Después cambia cualquier credencial guardada en el mismo sitio (repositorio, fichero de entorno, imagen de contenedor) y revisa el registro de uso para fechar la filtración. Averigua por dónde salió para que no se repita. En las aplicaciones que mantenemos, las claves están en un gestor de secretos, nunca en el código.¿Quién responde ante una vulnerabilidad o un incidente, y en qué horario?
Nuestro equipo, en horario laboral; fuera de él, la monitorización y las alertas automáticas avisan y el equipo actúa al inicio de la siguiente jornada. Si necesitas una persona de guardia fuera de horario, se contrata como opción. Por defecto: ventana de respuesta inicial de 4 horas para CVE alta, parche disponible en menos de 48 horas y comunicación al cliente desde el primer momento; si el impacto es una brecha de datos personales, activamos también la notificación a la AEPD en 72 horas. Todo esto va incluido en el contrato de mantenimiento.¿Qué requisitos de seguridad exige el RGPD a una aplicación web?
En la capa técnica: cifrado en tránsito (TLS 1.2/1.3) y en reposo (BD y backups); control de accesos por rol con MFA en accesos sensibles; registros auditables del acceso a datos personales; gestión de cookies con consentimiento real, no dark patterns; flujos de borrado y portabilidad de datos accesibles al usuario; plan de notificación a la AEPD en 72 horas ante brecha. La parte organizativa (DPO, política de privacidad, evaluaciones de impacto) la firma una asesoría legal aparte.
El siguiente paso
¿Revisamos tu aplicación
antes de que pregunte un cliente?
Cuéntanos qué aplicación quieres revisar. Empezamos por el alcance: qué entra, dónde está alojada y qué datos trata.