Cómo reportar una vulnerabilidad de forma responsable sin meterte en problemas

Encontrar algo raro en una web, una app o una cuenta no te convierte automáticamente en investigador de seguridad. A veces es un fallo real. A veces es una mala configuración. Y otras veces es una estafa, una alerta de cuenta o un problema que debe tratarse por otro canal.

La clave está en no improvisar. El responsible disclosure, o divulgación responsable, consiste en avisar de una posible vulnerabilidad de forma útil, limitada y segura: sin explotar más de lo necesario, sin acceder a datos ajenos, sin publicar detalles antes de tiempo y usando el canal oficial del proyecto o empresa afectada.

Esta guía está pensada para personas que creen haber encontrado un fallo y quieren actuar bien desde el principio: estudiantes, perfiles técnicos junior, responsables de pequeñas webs, usuarios curiosos o desarrolladores que han visto un comportamiento inesperado en un sistema propio o autorizado.

Qué significa responsible disclosure

Responsible disclosure significa comunicar una vulnerabilidad de forma coordinada con quien puede corregirla. No es “hacer hacking” contra cualquier objetivo. No es probar hasta dónde puedes llegar. No es presionar públicamente a una empresa para conseguir una recompensa.

Un reporte responsable tiene tres ideas centrales:

• respetar el alcance autorizado;
• reunir evidencia mínima y redactada;
• avisar por un canal verificable para que el equipo pueda investigar y corregir.

Si el programa tiene una política de divulgación de vulnerabilidades, un archivo `security.txt`, una página de seguridad, un programa de bug bounty o un correo oficial, esas reglas mandan. Si no hay reglas claras, el enfoque debe ser todavía más conservador: documentar lo mínimo, no seguir probando y buscar un canal de contacto legítimo.

Antes de tocar nada: alcance, autorización y sentido común

El error más habitual es confundir curiosidad con autorización. Que una web sea pública no significa que puedas probarla libremente. Que una aplicación devuelva un error no significa que puedas automatizar pruebas, abrir rutas que no te pertenecen o intentar confirmar el impacto con datos reales.

Antes de hacer cualquier comprobación, pregúntate:

• ¿Estoy dentro de un entorno propio, de laboratorio o explícitamente autorizado?
• ¿Existe una política pública que permita reportes de seguridad?
• ¿El programa define qué dominios, apps o cuentas están dentro de alcance?
• ¿Hay pruebas prohibidas, como denegación de servicio, ingeniería social, spam, scraping, fuzzing agresivo o acceso a datos de terceros?
• ¿Puedo explicar lo observado sin repetir acciones arriesgadas?

Si la respuesta no está clara, no sigas probando. En responsible disclosure, detenerse a tiempo es parte de la calidad del reporte.

Cuándo debes parar

Debes parar en cuanto tengas una señal razonable de que puede existir un fallo. No necesitas demostrar el máximo impacto. No necesitas buscar más usuarios afectados. No necesitas descargar datos. No necesitas repetir la prueba muchas veces.

Párate especialmente si aparece cualquiera de estas situaciones:

• ves información de otra persona, aunque sea parcialmente;
• aparecen tokens, cookies, claves, documentos privados o identificadores internos;
• una acción podría modificar datos, borrar contenido o afectar disponibilidad;
• el sistema empieza a responder con errores repetidos;
• la única forma de confirmar el fallo sería saltarte controles de acceso;
• el programa no autoriza expresamente el tipo de prueba que estás imaginando.

Una buena regla práctica: si ya puedes explicar qué viste, dónde lo viste, cuándo ocurrió y por qué parece un problema de seguridad, probablemente tienes suficiente para reportar.

Cómo documentar sin exponer datos sensibles

Un reporte útil no necesita capturas llenas de datos personales ni logs completos. Necesita contexto limpio.

Incluye lo mínimo necesario:

• fecha y hora aproximada;
• activo afectado dentro del alcance autorizado;
• cuenta propia o entorno de prueba usado, si aplica;
• comportamiento esperado;
• comportamiento observado;
• impacto posible explicado sin exagerar;
• evidencia redactada, con datos sensibles ocultos;
• pasos generales para que el equipo entienda el flujo, sin payloads ni instrucciones de abuso;
• canal por el que estás disponible para aclaraciones.

Antes de enviar, revisa capturas y texto. Oculta correos, nombres, teléfonos, direcciones, tokens, IDs de sesión, cookies, cabeceras de autorización, claves API, datos de terceros y cualquier información que no sea imprescindible.

Si el problema que has visto no es una vulnerabilidad técnica sino una estafa, un SMS sospechoso o una suplantación, el camino es distinto. En ese caso tiene más sentido seguir una guía de prevención y respuesta, como esta explicación sobre cuando el problema no es una vulnerabilidad sino una estafa: https://javierberastegui.es/como-detectar-sms-fraudulentos

Cómo escribir un reporte claro

Un buen reporte no intenta impresionar. Intenta ahorrar tiempo al equipo que debe reproducir, clasificar y corregir.

Una estructura sencilla puede ser:

• Resumen: explica en dos o tres frases qué has observado. Evita tecnicismos innecesarios y no afirmes más de lo que sabes.
• Alcance y autorización: indica por qué crees que estabas dentro de un contexto permitido: entorno propio, laboratorio, programa público, cuenta de prueba o política oficial. Si no tienes autorización clara, dilo y explica que detuviste la actividad.
• Impacto potencial: describe el riesgo con prudencia. No conviertas una observación limitada en una afirmación absoluta. Si parece afectar a autenticación, acceso a cuentas o permisos, puedes explicarlo como hipótesis para triage, no como sentencia.
• Evidencia redactada: adjunta solo lo necesario. Una captura parcial, un timestamp, una descripción del flujo y un identificador de entorno propio suelen ser más seguros que un volcado completo.
• Pasos generales: describe el camino de forma suficiente para que el equipo entienda el contexto, pero sin incluir payloads, automatizaciones, bypasses, listas de rutas, credenciales, tokens o instrucciones reutilizables contra terceros.

Ejemplo seguro: “Al usar mi propia cuenta de prueba, observé que una sección mostraba información que no esperaba ver para ese perfil. No accedí a datos adicionales ni repetí la prueba después de confirmar el comportamiento.”

Si el fallo tiene relación con contraseñas, acceso o recuperación de cuentas, también puede encajar recomendar medidas posteriores como mejorar la seguridad de acceso: https://javierberastegui.es/passkeys-la-alternativa-a-las-contrasenas-que-mejora-tu-seguridad-online

Qué no debes incluir en el reporte

No incluyas:

• contraseñas, cookies, tokens o claves API;
• datos personales de terceros;
• capturas completas con información privada;
• código de explotación;
• scripts de escaneo o automatización;
• amenazas, presión pública o exigencias de pago;
• detalles publicados en redes antes de dar tiempo razonable a corregir;
• resultados obtenidos fuera del alcance autorizado.

También conviene evitar frases como “he hackeado vuestro sistema” o “puedo acceder a todo”. Es mejor usar lenguaje preciso: “he observado”, “parece indicar”, “podría permitir” o “recomiendo revisar”.

Dónde reportar una vulnerabilidad

Busca primero canales oficiales:

• página de seguridad del sitio;
• archivo `security.txt` si existe;
• programa de bug bounty o vulnerability disclosure policy;
• repositorio oficial del proyecto, si permite reportes privados de seguridad;
• correo o formulario corporativo verificado;
• soporte oficial, si no hay canal específico.

No envíes detalles técnicos sensibles por redes sociales públicas. No publiques capturas. No contactes a empleados al azar con información delicada si existe un canal formal.

Si no encuentras canal claro, redacta un primer mensaje muy breve: indica que crees haber encontrado un posible problema de seguridad, que no vas a compartir detalles por un canal inseguro y que necesitas saber cuál es el contacto adecuado.

Qué esperar después de reportar

Después del envío puede haber silencio, triage, petición de aclaraciones o cierre como “no aplicable”. No todos los hallazgos son vulnerabilidades. No todos los programas pagan recompensas. Y no todos los equipos tienen la misma madurez de respuesta.

Lo razonable es mantener un tono profesional:

• conserva una copia de tu reporte;
• responde si piden aclaraciones dentro del alcance;
• no sigas probando por tu cuenta;
• no publiques detalles mientras el equipo investiga;
• acepta que puede haber duplicados o bajo impacto;
• si existe una política de disclosure, respeta sus plazos.

La divulgación responsable funciona mejor cuando ambas partes reducen el riesgo: quien reporta limita la información y quien recibe corrige, comunica y agradece de forma ordenada.

Cómo practicar sin cruzar límites

Si quieres aprender, practica en laboratorio. Usa aplicaciones deliberadamente vulnerables, entornos locales, máquinas de entrenamiento o repositorios educativos que indiquen claramente su finalidad. No uses empresas reales, tiendas online, universidades, administraciones o servicios de terceros como campo de pruebas.

Para este artículo he dejado un recurso práctico en el repo de hacking: una checklist, una plantilla y un helper local para preparar un reporte de responsible disclosure sin exponer datos sensibles ni hacer llamadas externas.

Recurso en GitHub: https://github.com/javierberastegui/hacking/tree/main/recursos/responsible-disclosure

El recurso no sirve para buscar vulnerabilidades ni para probar sistemas. Sirve para ordenar un reporte cuando ya tienes una observación dentro de un alcance autorizado: qué viste, qué impacto podría tener, qué evidencia mínima puedes compartir y qué información debes eliminar antes de enviar.

Material opcional para trabajar de forma más segura

No necesitas comprar nada para reportar una vulnerabilidad de forma responsable. Lo importante es respetar el alcance, detenerte a tiempo y usar el canal oficial.

{"kind":"rich_text","segments":[{"type":"text","text":"Aun así, si vas a gestionar cuentas importantes o comunicarte con equipos de seguridad, puede tener sentido reforzar tu higiene digital: una "},{"type":"link","text":"llave compatible con FIDO2/passkeys","href":"https://www.amazon.es/s?k=llave+seguridad+FIDO2+passkeys&tag=aturitmodigit-21","rel":"sponsored noopener noreferrer","target":"_blank","affiliate":true,"source":"amazon_affiliate_opportunity_autolink"},{"type":"text","text":" puede ayudarte a reducir el riesgo de acceso no autorizado; un gestor de contraseñas puede ayudarte a no reutilizar claves; y una plantilla o cuaderno puede servir para ordenar evidencias sin copiar datos sensibles."}]}

Son apoyos opcionales, no garantías. Ningún accesorio sustituye la autorización, la prudencia ni una buena documentación.

Checklist rápida antes de enviar

Antes de pulsar “enviar”, revisa esto:

• ¿El activo estaba dentro de alcance?
• ¿Has dejado de probar en cuanto tuviste evidencia suficiente?
• ¿Has eliminado datos personales, tokens, cookies y secretos?
• ¿El reporte explica impacto sin exagerar?
• ¿Has usado un canal oficial o verificable?
• ¿No incluyes código ofensivo, payloads ni automatización?
• ¿No estás pidiendo recompensas fuera de un programa formal?
• ¿Puedes defender que tu intención y tus acciones fueron proporcionales?

Si alguna respuesta te genera dudas, simplifica el reporte y elimina información. En seguridad, más detalle no siempre significa mejor reporte. A veces significa más riesgo.

Idea final

La divulgación responsable no va de demostrar hasta dónde puedes llegar. Va de avisar a tiempo, con límites claros y evidencia suficiente para que alguien pueda corregir.

Si crees que has encontrado una vulnerabilidad, el mejor movimiento suele ser el menos espectacular: parar, documentar lo mínimo, redactar con cuidado y usar el canal oficial.

{"label":"Aviso de afiliación","text":"Este artículo puede incluir enlaces de afiliado de Amazon. Si compras desde ellos, puedo recibir una comisión sin coste adicional para ti."}