Resumen

  • draft-ietf-httpapi-privacy-06 sitúa el fallo antes del 3xx: una API autenticada puede soltar una clave, cookie o bearer token en HTTP antes de recibir instrucciones para repetir por HTTPS.
  • HSTS, los registros HTTPS de DNS, el cierre del puerto 80, las restricciones de la credencial y el comportamiento del cliente son barreras distintas y temporales; la URL final no demuestra que todas actuaron.
  • Si una credencial llega en claro, el servidor debe rechazar sin revelar su validez, clasificar la exposición y decidir revocación. El borrador fue aprobado por el IESG y pasó a la cola del RFC Editor, pero el 1 de octubre de 2026 aún no era un RFC.

Hay errores que fallan ruidosamente y otros que entregan el resultado correcto. Escribir http:// en la base de una API puede pertenecer al segundo grupo. La biblioteca abre el canal, añade la autorización, recibe una redirección, negocia TLS y repite. El programa sigue funcionando, por eso la credencial puede continuar expuesta durante meses.

La revisión 06 obliga a separar el orden causal. Una respuesta HTTP sólo aparece después de que la petición haya cruzado la red. La conexión cifrada posterior protege bytes posteriores. No vuelve confidenciales los anteriores.

El último estado borra la primera decisión

En navegación humana, redirigir desde HTTP suaviza un punto de entrada imperfecto. En una integración automática no hace falta esa cortesía: el esquema ya está en configuración y el cliente posee autoridad reutilizable. El comportamiento indulgente convierte un error de despliegue en una rutina invisible.

El informe de mayo de 2024 que impulsó el trabajo nació de una omisión de una letra y documentó una muestra de endpoints conocidos. Sus nombres no deben usarse como censo vigente; algunos cambiaron y muchas pruebas emplearon valores de ejemplo. La lección verificable no depende de la lista: el éxito funcional puede coexistir con la pérdida de secreto.

Por eso conviene reconstruir recibos separados. La URI configurada demuestra intención. DNS y el registro HTTPS demuestran descubrimiento. HSTS demuestra estado previo si el cliente lo conserva. El primer flujo demuestra si salieron bytes de autorización. El 3xx o el 403 demuestra la reacción del extremo que contestó. El segundo handshake demuestra su propia protección. La revocación demuestra el destino de la credencial. La autorización y el commit demuestran el efecto de negocio.

El control debe llegar antes que el token

HSTS, definido en RFC 6797, puede exigir seguridad para conexiones futuras. Se aprende por una conexión segura anterior y depende de almacenamiento persistente. Un servidor no puede atribuir esa memoria a un cliente que nunca la implementó.

Los registros HTTPS de RFC 9460 trasladan información al momento de descubrir el servicio. Aun así, el cliente debe consultarlos y una ruta o resolución hostil puede ocultarlos. Usarlos junto con HSTS reduce probabilidades; no produce una prueba absoluta de primera conexión.

Cerrar HTTP en el servidor auténtico impide que ese servidor reciba la clave por el puerto claro. No impide que un atacante activo finja ser el extremo ausente. El cliente conserva la obligación decisiva: no adjuntar un secreto hasta haber elegido un transporte seguro.

También puede actuar la credencial. El atributo Secure de RFC 6265 restringe cookies. El esquema secret-token de RFC 8959 puede comunicar expectativas de uso. Una cabecera privada carece de esa protección salvo que la biblioteca y la política la añadan de forma explícita.

Un 403 uniforme evita una segunda fuga

Cuando la infraestructura no permite cerrar el puerto 80, el borrador aconseja contestar 403 a cualquier petición insegura que contenga credenciales, sean válidas o no. RFC 9110 permite que la negativa responda a una razón distinta de la suficiencia de la credencial. Una diferencia de cuerpo, tiempo o código convertiría el endpoint en un comprobador de claves.

El 403 no borra el incidente. Una API key o bearer token transmitido directamente es autoridad copiable y debe considerarse potencialmente comprometido. Una firma o MAC puede revelar sólo un derivado; entonces importan el alcance, nonce, cobertura y posibilidad de repetición. No todas las peticiones autenticadas exponen el mismo objeto.

Revocar automáticamente también concede poder. Un atacante puede enviar muchas conjeturas por HTTP para intentar invalidar una real. Límites de conexión y tasa, avisos y periodos controlados forman parte del diseño. La protección contra denegación no autoriza a etiquetar como segura una clave observada en claro.

Aprobación documental no es conformidad operacional

El Datatracker muestra un documento del grupo HTTPAPI destinado a Best Current Practice. El historial registra aprobación del IESG y entrada en RFC Editor Queue el 5 de junio de 2026. A 1 de octubre seguía siendo la revisión 06 del 11 de mayo, sin número RFC.

Ese recorrido demuestra revisión y consenso, no despliegue. La documentación señala que no se presentaron informes específicos de implementación. El repositorio permite auditar el texto; no demuestra qué hace una versión concreta de un SDK.

RFC 7258 añade una razón más amplia para cifrar: la vigilancia generalizada es un ataque. Incluso sin token, una petición revela rutas e intención. Con un bearer token, la observación puede transformarse en ejecución por otra parte.

El libro de evidencia empieza en la configuración

Registrar URI exacta, biblioteca y versión, política de redirección, regla de incorporación de credenciales, excepción insegura, respuesta DNS y HTTPS RR, origen y edad de HSTS, primer esquema y puerto reales, identidad del extremo, clase de credencial sin guardar el secreto, primer estado y Location, destino TLS, clasificación de exposición, cuarentena o rotación, autorización, commit y resultado externo.

No convertir el vacío en éxito. hsts=ausente, https_rr=no_disponible, exposicion=posible y revocacion=pendiente son estados legítimos. El último span HTTPS no debe sobrescribir el primero.

La Especificación inicial mínima permite fijar una regla común pequeña: ningún secreto reutilizable por transporte inseguro. La Primacía del código en ejecución mira los primeros bytes reales. El espejo de la política descubre el poder de los valores por defecto. Las capas de realidad separan configuración, descubrimiento, exposición, respuesta, autorización y efecto.

Fuentes