Lo que también debe saber quien encarga un sitio web — cómo usar la guía «Cómo crear un sitio web seguro» de la IPA como checklist
· Actualizado el: · Go Komura · Creación de sitios web, Desarrollo web, Seguridad de la información, Vulnerabilidades, Inyección SQL, Cross-Site Scripting, IPA, WordPress, B2B
Pocas empresas pueden responder con fundamento «sí, está bien» cuando les preguntan: «¿la seguridad de nuestra página web está bien?».
Es habitual pensar que, como se lo hemos encargado a una empresa de diseño web, todo está bien, o que un sitio que es solo un catálogo corporativo no llama la atención de nadie. Pero basta con tener un formulario de contacto para que haya un programa procesando los valores introducidos, y si se usa un CMS como WordPress, tanto el panel de administración como los plugins son objetivos de ataque. Además, la mayoría de los ataques no apuntan deliberadamente a una empresa concreta, sino que buscan de forma automatizada sitios débiles.
Entonces, ¿con qué criterio se puede confirmar que «está bien»? El documento público que lleva mucho tiempo utilizándose como ese criterio es Cómo crear un sitio web seguro, de la IPA (Agencia de Promoción de Tecnología de la Información).
En este artículo organizamos lo que enseña este documento con un lenguaje comprensible tanto para quien encarga un sitio web como para quien lo gestiona.
1. Antes de nada, la conclusión
- «Cómo crear un sitio web seguro» es un documento que reúne 11 tipos de puntos débiles de los sitios web y sus medidas, basado en vulnerabilidades realmente notificadas a la IPA. No es útil solo para desarrolladores: también sirve como criterio para contratar y para la recepción de trabajos
- Las medidas se dividen en «solución fundamental» (elimina la causa) y «medida preventiva» (reduce el daño). La base es la solución fundamental, y la medida preventiva se añade como capa adicional
- La «Checklist de implementación de seguridad» adjunta puede usarse tal cual como lista de verificación al contratar y al recibir el trabajo de la empresa de diseño
- El anexo «Especificación de chequeo de salud web» sirve como criterio de los puntos a diagnosticar en las revisiones periódicas de un sitio en funcionamiento
- En la práctica de un sitio corporativo, los dos grandes riesgos son las partes que reciben entradas (como los formularios) y la operación del CMS (como WordPress). Al contratar, conviene definir también el sistema de operación posterior, para no dejar el sitio abandonado tras su lanzamiento
2. Qué es «Cómo crear un sitio web seguro»
«Cómo crear un sitio web seguro» es un documento dirigido a desarrolladores y responsables de sitios web que reúne medidas frente a las vulnerabilidades notificadas a la IPA con mayor número de reportes, o aquellas cuyo impacto es grande en caso de ataque. La versión más reciente disponible actualmente es la 7.ª edición revisada, con 115 páginas en total. El PDF que se distribuye fue actualizado como 4.ª reimpresión el 31 de marzo de 2021. Además del PDF, también se publican páginas HTML para cada vulnerabilidad.
El documento se organiza en tres capítulos.
| Capítulo | Contenido |
|---|---|
| Capítulo 1: Implementación de seguridad en aplicaciones web | Explica las amenazas y las medidas (solución fundamental y medida preventiva) para 11 tipos de vulnerabilidades |
| Capítulo 2: Iniciativas para mejorar la seguridad del sitio web | Iniciativas para elevar la seguridad de todo el sitio más allá de la implementación de la aplicación, como la operación del servidor |
| Capítulo 3: Casos de fallos | Explica 8 tipos de fallos habituales, con código fuente y ejemplos de corrección |
Además, aparte del cuerpo principal, se publican los siguientes documentos.
- Checklist de implementación de seguridad (formato Excel): una tabla para verificar si se han implementado las medidas del cuerpo principal
- Anexo «Cómo realizar llamadas SQL seguras»: un documento que profundiza en las medidas contra vulnerabilidades relacionadas con la base de datos
- Anexo «Especificación de chequeo de salud web»: una especificación que reúne 13 puntos de diagnóstico para revisar un sitio en funcionamiento
Todos ellos se pueden descargar de forma gratuita desde la página de la IPA.
2.1. Cómo considerar la vigencia del documento
Antes de usar este documento como referencia, hay una premisa que conviene tener presente. La 7.ª edición revisada se publicó en marzo de 2015, y desde entonces se han introducido correcciones en cada reimpresión; el PDF que se distribuye actualmente es la 4.ª reimpresión de la 7.ª edición, actualizada el 31 de marzo de 2021. En el momento de escribir este artículo (julio de 2026), aún no se ha publicado una 8.ª edición.
Aun así, se puede seguir usando como referencia porque lo que trata este documento son puntos débiles que se originan en la propia manera de construir una aplicación web. Mecanismos como incrustar valores de entrada en sentencias SQL o en HTML, identificar al usuario mediante una sesión, o enviar un correo a partir de los datos de un formulario, siguen siendo los mismos hoy. Los 11 tipos de vulnerabilidades y el enfoque de «solución fundamental / medida preventiva» siguen siendo válidos hoy como criterio de verificación de la implementación.
Dicho de otro modo, este documento no cubre las tendencias de amenazas de los últimos años. Temas como los ataques de ransomware, las intrusiones a través de proveedores o subcontratistas, o los riesgos asociados al uso de la IA generativa, quedan fuera del alcance original de este documento. Eso hay que complementarlo con documentos que se actualizan cada año.
| Documento | Alcance | Forma de actualización |
|---|---|---|
| Cómo crear un sitio web seguro | Qué se debe implementar en la aplicación web | 7.ª edición revisada en 2015, 4.ª reimpresión en 2021. Sin revisiones posteriores |
| 10 principales amenazas de seguridad de la información | Tendencias sobre qué ataques ocurren realmente en la actualidad | Publicación anual |
| Directrices de medidas de seguridad de la información para pymes | Cómo construir el sistema y la operación de toda la empresa | En cada revisión (la más reciente es la versión 4.0) |
No hace falta leer los tres por separado. Basta con repartir los roles —«el criterio de implementación va en este documento, las tendencias de amenazas más recientes en las 10 principales amenazas, y el sistema de la empresa en las directrices»— y consultar solo el que se necesite en cada momento. El contenido de la versión 2026 de las 10 principales amenazas se trata en el artículo sobre las 10 principales amenazas de seguridad de la información 2026, y la versión 4.0 de las directrices se trata en el artículo sobre la versión 4.0 de las directrices.
3. Leer las 11 vulnerabilidades desde «qué ocurre»
Las 11 vulnerabilidades que trata el capítulo 1 aparecen enumeradas con terminología orientada a desarrolladores, pero si se traducen a «qué ocurre en el propio sitio si se dejan sin resolver», se entiende que tampoco son un asunto ajeno para quien encarga el sitio.
La columna de la derecha muestra ejemplos de los lugares de un sitio corporativo donde esta vulnerabilidad suele plantear problemas. Comprobando si el propio sitio tiene esas mismas funciones, se puede identificar qué filas son relevantes.
| Vulnerabilidad | Qué ocurre si se deja sin resolver | Lugares de su sitio donde suele aplicarse |
|---|---|---|
| Inyección SQL | Se roba o se modifica el contenido de la base de datos, como el historial de consultas o los datos de los socios/miembros | El procesamiento de guardado de los formularios de contacto o solicitud de material, la búsqueda dentro del sitio, la búsqueda de datos de miembros, la gestión de artículos del CMS |
| Inyección de comandos del sistema operativo | El servidor es tomado y usado como trampolín para otros ataques | Procesos que llaman a programas externos, como el redimensionado de imágenes, la generación de PDF o la compresión/descompresión de archivos ZIP |
| Falta de comprobación de parámetros de nombre de ruta (path traversal / recorrido de directorios) | Se leen archivos del servidor que no estaban pensados para mostrarse | La función de descarga de materiales, la distribución de archivos para miembros, las pantallas que reciben el nombre de archivo como parámetro de la URL |
| Deficiencias en la gestión de sesiones | Otra persona puede suplantar la identidad del usuario e iniciar sesión en su lugar | El inicio de sesión de miembros, el panel de administración del CMS o del comercio electrónico, la página personal tras iniciar sesión |
| Cross-Site Scripting (XSS) | En el navegador del visitante se ejecutan pantallas falsas o procesos no autorizados que roban información | La pantalla de confirmación de un formulario, la visualización de resultados de la búsqueda interna, las secciones de reseñas o comentarios, y cualquier lugar donde el contenido introducido se muestre en pantalla |
| CSRF (Cross-Site Request Forgery / falsificación de petición en sitios cruzados) | Un usuario con la sesión iniciada realiza, sin darse cuenta, una operación que no había pretendido | Cambios en los datos de registro de un miembro, la baja de la cuenta, la confirmación de un pedido y otras operaciones que cambian el estado tras iniciar sesión |
| Inyección de cabeceras HTTP | Se explota para mostrar páginas falsas o redirigir a otro sitio | Procesos que construyen el destino de una redirección o una cookie a partir del valor de un parámetro, como la URL de retorno tras iniciar sesión |
| Inyección de cabeceras de correo | El formulario de contacto se explota como dispositivo de envío de correo no deseado | El correo de respuesta automática o de notificación interna del formulario de contacto, especialmente cuando el remitente o el asunto usan valores introducidos por el usuario |
| Clickjacking | Se superponen botones invisibles y se induce al usuario a hacer clics no deseados | Pantallas de operaciones importantes que se confirman con un solo clic, como la baja de la cuenta, el cambio de configuración o la confirmación de un pedido |
| Desbordamiento de búfer (buffer overflow) | El programa es tomado y se ejecuta un proceso arbitrario | Programas propios escritos en C/C++ o middleware antiguo. En sitios habituales construidos con PHP, Java, Ruby, etc., normalmente no suele ser un problema |
| Falta de control de acceso o de control de autorización | Personas sin permisos pueden entrar a páginas de miembros o funciones de administración | Páginas exclusivas para miembros, el panel de administración, las pantallas de detalle donde, al modificar el ID incluido en la URL, se pueden ver los datos de otra persona |
Por ejemplo, la «inyección de cabeceras de correo» se aplica directamente al formulario de contacto de un sitio de presentación corporativa. Un formulario con medidas insuficientes puede explotarse como origen de correo no deseado, dañando incluso la reputación del dominio de la empresa (si el correo llega o no a su destinatario). Como se trató en causas de que el correo del formulario de contacto no llegue, este problema de que el correo del formulario deje de llegar se traduce directamente en pérdida de oportunidades de negocio.
4. «Solución fundamental» y «medida preventiva» — el enfoque de las medidas
Uno de los puntos fuertes de este documento es que presenta las medidas divididas en dos tipos.
- Solución fundamental: una implementación que elimina directamente la causa de la vulnerabilidad. Por ejemplo, en el caso de la inyección SQL, construir la sentencia SQL con marcadores de posición (placeholders) en lugar de concatenación de cadenas
- Medida preventiva: una medida que, si la vulnerabilidad persiste, reduce la probabilidad de éxito del ataque o el daño causado. Por ejemplo, no mostrar el mensaje de error tal cual en el navegador
Esta clasificación sirve como vara de medir para quien encarga el sitio al recibir explicaciones sobre seguridad. La explicación «instalamos un WAF (un mecanismo que detecta y bloquea ataques), así que puede estar tranquilo» se refiere a una medida preventiva, y no sustituye a la solución fundamental de la propia aplicación. Por el contrario, implementar la solución fundamental y añadir un WAF encima es una configuración razonable. Basta con distinguir de qué capa se está hablando para poder valorar bastante bien si una propuesta tiene sentido.
5. Cómo usarlo al contratar y recibir el trabajo
«Cómo crear un sitio web seguro» es un documento orientado a desarrolladores, pero su utilidad práctica para quien encarga el sitio está en que puede usarse como criterio para exigir y verificar.
- Etapa de presupuesto y requisitos: incluir en las especificaciones o en el RFP una frase como «implementar medidas contra las vulnerabilidades que señala ‘Cómo crear un sitio web seguro’ de la IPA». Nombrar explícitamente el criterio hace que el requisito sea más claro que una expresión ambigua como «tener en cuenta la seguridad»
- Etapa de recepción del trabajo: pedir la entrega de los resultados de verificación de los puntos correspondientes de la checklist de implementación de seguridad
- Etapa de contrato: dejar por escrito quién actualizará el CMS, los plugins y el servidor tras la publicación, y si la respuesta ante una vulnerabilidad descubierta entra dentro del contrato de mantenimiento o requiere un presupuesto aparte
El tercer punto es especialmente importante. La seguridad de un sitio web no queda completa en el momento en que se termina de construir, sino que se mantiene siguiendo las nuevas vulnerabilidades que se descubren tras la publicación. Esta cuestión de «quién se sigue haciendo cargo» tiene la misma estructura que el alcance del mantenimiento que se organizó en el artículo sobre contratos de desarrollo encargado y mantenimiento operativo.
5.1. Ejemplo de texto para especificaciones y RFP
Con «tener en cuenta la seguridad» no queda claro con qué se considera cumplido el requisito. Especificar el nombre del documento y los entregables convierte el requisito en algo verificable. Por ejemplo, se puede redactar así:
Requisitos de seguridad
- La aplicación web de este proyecto deberá implementar, para cada una de las vulnerabilidades que señala el capítulo 1 de «Cómo crear un sitio web seguro — 7.ª edición revisada» de la IPA, las medidas clasificadas en dicho documento como «solución fundamental».
- En el momento de la entrega, deberán presentarse los resultados de la autoverificación de todos los puntos de la «Checklist de implementación de seguridad» adjunta a dicho documento. Los puntos considerados «no aplicable» deberán indicar también el motivo (por ejemplo, no contar con la función correspondiente).
- Para las pantallas con procesamiento dinámico (formulario de contacto, búsqueda, inicio de sesión, descarga de archivos, etc.), el documento de diseño deberá describir la política de tratamiento de los valores de entrada y del procesamiento de escape en la salida.
- El contrato de mantenimiento deberá especificar quién actualizará el CMS, el tema, los plugins y el entorno de ejecución tras la publicación, con qué frecuencia, y cómo se gestionarán el tiempo de respuesta y el costo en caso de que se publique una vulnerabilidad urgente.
No es necesario incluir los cuatro puntos desde el principio. Para un sitio centrado en presentar la empresa, basta con los puntos 1 y 2: la conversación en la etapa de recepción del trabajo será completamente distinta a la de encargar el proyecto diciendo simplemente «la seguridad se la dejamos a ustedes».
5.2. Contenido de la checklist
La checklist es un único archivo Excel que enumera, para cada uno de los 11 tipos de vulnerabilidades, los 47 puntos de implementación correspondientes al capítulo 1 de «Cómo crear un sitio web seguro — 7.ª edición revisada». Cada fila se compone del tipo de vulnerabilidad, la naturaleza de la medida (solución fundamental / medida preventiva), la casilla de verificación (implementado / sin implementar / no aplicable), el texto del punto a implementar, y el número de la explicación correspondiente en el cuerpo principal.
Los puntos reales están redactados, por ejemplo, de esta manera:
| Vulnerabilidad | Naturaleza de la medida | Punto a implementar | Explicación |
|---|---|---|---|
| Inyección SQL | Solución fundamental | Implementar la construcción de todas las sentencias SQL mediante marcadores de posición (placeholders). | 1-(i)-a |
| Inyección SQL | Medida preventiva | No mostrar el mensaje de error tal cual en el navegador. | 1-(iii) |
| Inyección de cabeceras de correo | Solución fundamental | Fijar las cabeceras de correo a valores constantes y enviar toda entrada externa únicamente al cuerpo del mensaje. | 8-(i)-a |
(El texto de los puntos a implementar es una cita de la «Checklist de implementación de seguridad» adjunta a «Cómo crear un sitio web seguro — 7.ª edición revisada» de la IPA)
Lo que resulta útil para quien encarga el sitio es que la casilla de verificación incluya la opción «no aplicable». En un sitio sin función de inicio de sesión, es normal que el punto de gestión de sesiones quede en blanco, pero sin una anotación no se puede distinguir si es porque «no aplica» o porque «se pasó por alto». Con solo pedir que se anote «no aplicable» junto con el motivo, la conversación en la etapa de recepción del trabajo se vuelve mucho más concreta.
6. Someter el sitio en funcionamiento a un «chequeo de salud»
Para los sitios que ya están publicados, resulta útil el anexo «Especificación de chequeo de salud web». Se trata de una especificación que reúne 13 puntos de diagnóstico para revisar la seguridad de un sitio web en funcionamiento, y también sirve como referencia del contenido al contratar un servicio de diagnóstico de vulnerabilidades.
En los sitios corporativos de pequeñas y medianas empresas, en la práctica hay dos puntos donde el riesgo tiende a concentrarse especialmente:
- Las partes que reciben entradas: el formulario de contacto, el cuadro de búsqueda, el inicio de sesión de miembros, etc. La mayoría de las vulnerabilidades del capítulo 1 están relacionadas con esta parte
- La operación del CMS: los sitios en los que se ha detenido la actualización del núcleo, el tema o los plugins de WordPress u otro CMS son el patrón típico de sitios que acaban alterados al explotarse un punto débil ya conocido. Hay muchísimos casos en los que el sitio queda abandonado sin haberse definido de quién es la responsabilidad de actualizarlo
Si desea reconsiderar la carga de actualización del CMS junto con todo el sistema de operación, también puede servirle de referencia el artículo sobre la migración desde WordPress. Además, existe también la decisión de diseño de reducir de entrada el procesamiento dinámico y adoptar una configuración de sitio estático, con lo que se reduce la propia superficie de ataque. El hecho de que en nuestra empresa adoptemos, para la creación de sitios, una configuración estática basada en el sistema de diseño de la Agencia Digital es también una extensión de este enfoque.
Cabe señalar que la operación segura de un sitio web también aparece como punto de verificación en el autodiagnóstico de la versión 4.0 de las «Directrices de medidas de seguridad de la información para pymes» de la IPA. Para conocer su ubicación dentro del conjunto de medidas de seguridad de toda la empresa, consulte el artículo sobre la versión 4.0 de las directrices.
7. Mini diccionario de términos
A continuación se resumen los términos usados en este artículo que suelen aparecer en las reuniones con la empresa de diseño web. Si puede explicar el significado de cada uno en una línea, podrá juzgar por sí mismo, al recibir una explicación, si se está hablando de una solución fundamental o de una medida preventiva.
| Término | Significado |
|---|---|
| Vulnerabilidad | Un punto débil originado en la forma de construir un programa, que puede explotarse en un ataque. Entre los defectos, es el que afecta a la seguridad |
| Solución fundamental | Una implementación que elimina directamente la causa de la vulnerabilidad. En la clasificación del documento de la IPA, es la base de las medidas |
| Medida preventiva | Una medida que, cuando la causa persiste, reduce la probabilidad de éxito del ataque o la magnitud del daño. No sustituye a la solución fundamental |
| Marcador de posición (placeholder) | Una forma de escritura en la que primero se reserva con un símbolo el lugar donde irá un valor dentro de una sentencia SQL, y el valor se pasa después al motor de base de datos. Como no se construye la sentencia SQL concatenando cadenas, los caracteres introducidos no se interpretan como parte de la sentencia SQL |
| Procesamiento de escape | Sustituir los caracteres que tienen un significado especial en HTML (< > & “ etc.) por una notación que se muestra tal cual como carácter, antes de enviarlos a la salida. Es la base de las medidas contra XSS |
| WAF | Web Application Firewall (cortafuegos de aplicaciones web). Un mecanismo que supervisa el tráfico hacia el sitio web y bloquea lo que considera un ataque. Se ubica como medida preventiva |
| CMS | Content Management System (sistema de gestión de contenidos). Un mecanismo que permite actualizar artículos e imágenes desde el navegador, como WordPress. La actualización del núcleo, el tema y los plugins es la clave de la operación |
| Diagnóstico de vulnerabilidades | Revisar si existen puntos débiles en un sitio en funcionamiento. Los 13 puntos del anexo «Especificación de chequeo de salud web» de la IPA sirven como referencia del contenido a solicitar |
Resumen
Repasamos los puntos clave de «Cómo crear un sitio web seguro» de la IPA.
- Un documento de referencia sobre 11 tipos de puntos débiles de los sitios web y sus medidas, basado en vulnerabilidades realmente notificadas a la IPA (7.ª edición revisada, 115 páginas en total)
- Las medidas se dividen en dos capas: solución fundamental y medida preventiva. Las medidas preventivas, como el WAF, no sustituyen a la solución fundamental
- Quien encarga el sitio puede usarlo así: especificar el nombre del documento en los requisitos, recibir el trabajo con la checklist, y definir por contrato el sistema de actualización tras la publicación
- Para un sitio en funcionamiento, realizar revisiones periódicas usando la «Especificación de chequeo de salud web» como referencia
- El riesgo realista de un sitio corporativo tiende a concentrarse en el procesamiento de entradas, como los formularios, y en el abandono del CMS
La seguridad tiende a plantearse como una disyuntiva entre «gastar lo que diga el experto» o «no hacer nada», pero con solo conocer un criterio público, se puede exigir y verificar con las propias palabras.
Para quienes estén considerando la creación o renovación de un sitio web
En KomuraSoft LLC, al crear o renovar un sitio web, hacemos propuestas siguiendo el enfoque presentado en este artículo: desde la implementación de los formularios hasta una configuración estática que no dependa en exceso del CMS, incluyendo el sistema de actualización tras la publicación. Puede consultarnos incluso desde la etapa de «no sé en qué estado está mi sitio actual», para revisar la situación actual.
Artículos relacionados
Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.
Análisis del examen de Especialista en Seguridad de la Información Registrado, otoño de Reiwa 5, tarde, pregunta 1 — el XSS almacenado donde 16 reseñas se muestran como solo 2
A partir de la pregunta 1 de la tarde del examen de Especialista en Seguridad de la Información Registrado, otoño de Reiwa 5, se explica ...
Las 10 principales amenazas de seguridad de la información 2026 — cómo leer el ranking y qué deben abordar realmente las pymes
En el «Top 10 de amenazas de seguridad de la información 2026» de IPA, el ransomware repite en el 1.º puesto por 11.º año consecutivo, la...
Medidas de seguridad para pymes, por dónde empezar — Cómo recorrer la versión 4.0 de la «Guía de medidas de seguridad de la información para pymes» del IPA
¿Por dónde empezar la seguridad en una pyme? La guía v4.0 del IPA explica los seis principios básicos, la autoevaluación de 5 minutos y S...
Análisis del examen de Especialista en Seguridad de la Información Registrado, primavera de Reiwa 6, tarde, pregunta 1 — el alg=none de JWT, la autorización de API y las medidas provisionales de WAF
A partir de la pregunta 1 de la tarde del examen de Especialista en Seguridad de la Información Registrado, primavera de Reiwa 6, se expl...
Especialista en Seguridad de la Información, otoño de Reiwa 5, pregunta 2 de la tarde — Archivos sustraídos por el Wi-Fi de invitados
A partir de la pregunta 2 de la tarde de R5 otoño, explica cómo se filtran archivos por el Wi-Fi de invitados pese a bloquear el USB, y r...
Temas relacionados
Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.
Temas técnicos de Windows
Portal sobre desarrollo de Windows, investigación de fallos y aprovechamiento de activos existentes.
Temas de Web y SEO
Creación de sitios, SEO, recorrido de contacto y diseño de enlaces internos.
Servicios relacionados con este tema
El artículo está directamente relacionado con los siguientes servicios.
Desarrollo de sitios web
En la creación o renovación de un sitio web, la implementación del formulario y la configuración del CMS —las consideraciones de seguridad tratadas en este artículo— inciden directamente en la calidad del desarrollo.
Consultoría técnica y revisión de diseño
Identificar dónde están los riesgos de un sitio o sistema web existente, y cómo redactar los requisitos de seguridad en las especificaciones de contratación, forma parte del ámbito de la consultoría técnica que incluye revisión de diseño.
Preguntas frecuentes
Preguntas habituales en las consultas sobre el tema del artículo.
- ¿Qué tipo de documento es «Cómo crear un sitio web seguro»?
- Es un documento de seguridad publicado por la IPA (Agencia de Promoción de Tecnología de la Información, un organismo administrativo independiente de Japón), dirigido a desarrolladores y responsables de sitios web. Recoge, de entre la información sobre vulnerabilidades notificada a la IPA, aquellas con mayor número de reportes o mayor impacto, y explica las amenazas y las medidas correspondientes. La última versión disponible, la 7.ª edición revisada, se publicó en marzo de 2021 y tiene 115 páginas en total. Además del cuerpo principal, se publican gratuitamente la «Checklist de implementación de seguridad» y los anexos «Cómo realizar llamadas SQL seguras» y «Especificación de chequeo de salud web».
- ¿Es necesario aplicar medidas de seguridad incluso en un sitio web que es poco más que un catálogo de la empresa?
- Sí, es necesario. Si el sitio tiene un formulario de contacto, hay un programa que procesa los valores introducidos, y si usa un CMS como WordPress, el panel de administración y los plugins se convierten en objetivos de ataque. Los atacantes no eligen sus objetivos según el tamaño de la empresa: buscan sitios vulnerables de forma automatizada y los explotan para alterar contenido, usarlos como trampolín para distribuir virus o como origen de correo no deseado. Lo peligroso de un sitio web es que, además de ser víctima, la empresa puede convertirse a la vez en agresora frente a sus clientes y visitantes.
- ¿Cuál es la diferencia entre la «solución fundamental» y la «medida preventiva»?
- «Cómo crear un sitio web seguro» presenta las medidas divididas en dos tipos. La solución fundamental es el método de implementación que elimina directamente la causa de la vulnerabilidad (por ejemplo, usar marcadores de posición —placeholders— para construir las sentencias SQL). La medida preventiva es una medida que, cuando la vulnerabilidad persiste, reduce la probabilidad de éxito del ataque o el daño causado (por ejemplo, no mostrar el mensaje de error tal cual). Como la medida preventiva por sí sola deja intacta la causa, el orden correcto es partir de la solución fundamental como base y añadir la medida preventiva como capa adicional.
- ¿Qué debo confirmar sobre seguridad al encargar el desarrollo a una empresa de diseño web?
- Recomendamos confirmar, al menos, estos tres puntos en la etapa de presupuesto: (1) si se implementan las medidas contra las vulnerabilidades que señala «Cómo crear un sitio web seguro»; (2) si se pueden mostrar los resultados de verificación mediante la checklist de implementación de seguridad adjunta u otro medio equivalente; y (3) quién se encargará de actualizar el CMS y los plugins después de la publicación (el alcance del contrato de operación y mantenimiento). Añadir requisitos de seguridad después implica un retrabajo considerable, por lo que es importante dejarlos por escrito antes de firmar el contrato.
Perfil del autor
Página de presentación del autor del artículo.
Go Komura
Representante de KomuraSoft LLC
Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.