Cabeceras de seguridad para una API web

Question

Cabeceras de seguridad para una API web

#1 de Arminius (22 votos)

8

Acabo de recibir una configuración, una API de Golang detrás de un servidor Caddy que tiene HTTPS de forma predeterminada a través de Let's Encrypt, el servidor envía todas las solicitudes a la API de la Web. Así que fui a probar la "seguridad" de mi servidor web en sitios como securityheaders.io. Me dieron una F, así que agregué los encabezados que exigían y obtuve una A

Access-Control-Allow-Methods "GET, POST, OPTIONS"
Strict-Transport-Security "max-age=31536000;"
Content-Security-Policy "script-src 'self'"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
-Server

Estos son los encabezados que tengo actualmente, pero me gustaría saber si son necesarios para la seguridad cuando lo que estoy haciendo no es un sitio web, sino un servidor web de API, algo así como

Access-Control-Allow-Methods "GET, POST, OPTIONS"
-Server

Básicamente, ¿todos esos encabezados de seguridad son necesarios si solo desea solicitar su API?

proxy api header

pregunta Whiteclaws 07.01.2017 - 01:05

fuente

1 respuesta

Lea otras preguntas en las etiquetas proxy api header

Olfateando, husmeando, falsificando ¿La ocultación de las versiones de software del servidor tiene un efecto notable en la seguridad?

score 22 · Accepted Answer

La comprobación de encabezados de una lista no es la mejor técnica para hacer valer la seguridad de un sitio. Los servicios como securityheaders.io pueden apuntarle en la dirección correcta, pero todo lo que hacen es compararlos con una lista de configuraciones propuestas sin ningún contexto sobre su aplicación. En consecuencia, algunas de las propuestas no tendrán ningún impacto en la seguridad de un punto final de API que no sirve más que respuestas JSON.

Strict-Transport-Security tiene sentido porque garantiza que los usuarios se conectarán directamente a su sitio a través de HTTPS después de su primera visita y hasta que se alcance el tiempo de espera max-age , lo que evitará los ataques de baja calificación. Incluso un punto final de API debería estar protegido con SSL, así que mantenga ese encabezado.
Access-Control-Allow-Methods: GET, POST, OPTIONS no es una opción de seguridad per se. Si su API funciona a través de las solicitudes de verificación previa de CORS , debe decidir qué métodos permite cruzar -Origin sitios a utilizar. Deshabilitar CORS podría hacer que su API no esté disponible. Si esa configuración particular es sensata, depende de su implementación.
X-XSS-Protection: 1; mode=block puede ser un buen adivice para sitios regulares porque le indica al Auditor XSS (que se implementa en los navegadores WebKit pero no a Firefox) que no renderice el sitio cuando detecta un intento XSS reflejado. Pero para una API que solo proporciona respuestas JSON y no ofrece contenido activo, este encabezado no ofrece ningún beneficio.
X-Content-Type-Options: nosniff evita que los navegadores hagan suposiciones sobre el tipo de contenido si el sitio no lo declaró correctamente. Si está ejecutando una API JSON, debe servir las respuestas con Content-Type: application/json . Si lo hace correctamente, no será necesario agregar la directiva nosniff .
X-Frame-Options: Deny evita que cualquier sitio web incruste su sitio en un marco HTML. Esa opción detiene los ataques de clickjacking cuando un atacante engaña a los usuarios para que interactúen con su sitio web a través de un marco disfrazado. Pero sin elementos interactivos, existe un riesgo limitado a través del encuadre de origen cruzado. Sin embargo, como hay ataques avanzados que implican arrastrar contenido fuera del marco que podría revelar respuestas JSON, es posible que aún desee dejar ese encabezado allí.
Content-Security-Policy headers controlan qué tipo de contenido desde qué origen puede interactuar su sitio (scripts, hojas de estilo, imágenes, etc.). Su configuración "script-src 'self' significa que solo se pueden cargar scripts del mismo origen. Un CSP es útil para los sitios regulares pero no tiene sentido para su punto final de API porque no sirve ningún contenido activo que pueda ser controlado por el CSP.
El encabezado Server especifica información sobre el servidor y el software que se ejecuta en él. A menudo se recomienda no enviar ese encabezado para no revelar nada sobre el software y las versiones de back-end.