[{"data":1,"prerenderedAt":171},["ShallowReactive",2],{"blog-tag-es-privacidad":3},{"tagName":4,"posts":5},"Privacidad",[6],{"id":7,"title":8,"author":9,"body":10,"category":134,"date":135,"description":136,"extension":137,"faq":138,"meta":160,"navigation":161,"path":162,"readingTime":163,"seo":164,"slug":165,"stem":166,"tags":167,"__hash__":170},"blog\u002Fblog\u002Fes\u002Fwhat-is-permissions-policy.md","¿Qué es la cabecera Permissions-Policy y por qué es importante?","EuroraCloud Team",{"type":11,"value":12,"toc":122},"minimark",[13,17,21,26,29,32,36,51,57,61,64,67,71,74,77,81,84,87,90,94,97,100,104,107,115,119],[14,15,8],"h1",{"id":16},"qué-es-la-cabecera-permissions-policy-y-por-qué-es-importante",[18,19,20],"p",{},"La cabecera Permissions-Policy es una cabecera de respuesta que permite a un sitio web controlar qué funciones del navegador pueden usar sus propias páginas, y cualquier contenido incrustado en ellas. Funciones como la cámara, el micrófono, la geolocalización y el pago pueden permitirse individualmente, restringirse a su propio origen, o desactivarse por completo. Configurarla significa que, incluso si un script o un tercero incrustado intenta acceder a una de esas funciones, el navegador lo rechaza a menos que su política lo permita, lo que reduce tanto su exposición en materia de privacidad como su superficie de ataque.",[22,23,25],"h2",{"id":24},"por-qué-existe-la-cabecera-permissions-policy","¿Por qué existe la cabecera Permissions-Policy?",[18,27,28],{},"Los navegadores modernos exponen muchas capacidades potentes a las páginas web: ubicación, cámara, micrófono, sensores de movimiento y más. Cualquier script que se ejecute en su página, incluidos los scripts de terceros que haya incrustado para analítica, chat o publicidad, puede en principio pedir al navegador que use esas capacidades. Permissions-Policy existe para que pueda declarar, al nivel de todo el sitio, cuáles de esas funciones están permitidas y para quién.",[18,30,31],{},"El propósito es cerrar la brecha entre lo que un navegador puede hacer y lo que su sitio realmente necesita. La mayoría de los sitios web nunca usan el acelerómetro ni la API de pago, y sin embargo, sin una política, esas funciones siguen siendo accesibles para cualquier código de la página. Según la documentación de MDN, cuando una política bloquea una función ni siquiera se pide permiso al usuario, y el intento de un script de usarla simplemente falla, que es exactamente la contención que desea para funciones que nunca tuvo intención de usar.",[22,33,35],{"id":34},"qué-hace-realmente-la-cabecera-permissions-policy","¿Qué hace realmente la cabecera Permissions-Policy?",[18,37,38,39,45,46,50],{},"La cabecera funciona como una lista de directivas, una por función, cada una con una lista de permitidos que indica qué orígenes pueden usarla. La sintaxis es el nombre de la función, un signo de igual, y los orígenes permitidos entre paréntesis, con varias directivas separadas por comas, por ejemplo geolocation=(), camera=(self). Una lista de permitidos vacía, escrita (), desactiva la función en todas partes; self solo la permite en su propio origen; un origen específico como (\"",[40,41,42],"a",{"href":42,"rel":43},"https:\u002F\u002Fexample.com",[44],"nofollow","\") permite ese origen; y ",[47,48,49],"code",{},"*"," la permite en todas partes, incluidos los marcos incrustados.",[18,52,53,54,56],{},"Un detalle útil es que cada función tiene una lista de permitidos predeterminada que se aplica cuando no dice nada, y según la función ese valor predeterminado es uno de ",[47,55,49],{},", self o ninguno. El valor de configurar la cabecera de forma explícita es, por tanto, que deja de depender de los valores predeterminados por función y toma en cambio una decisión deliberada y uniforme: desactivar todo lo que no usa, y limitar todo lo que sí usa a su propio origen o a los socios concretos que lo necesitan.",[22,58,60],{"id":59},"cómo-se-comporta-la-cabecera-con-los-iframes-incrustados","¿Cómo se comporta la cabecera con los iframes incrustados?",[18,62,63],{},"Esta es la parte con la que más gente tropieza, así que conviene ser preciso. Una función solo está disponible dentro de un iframe incrustado si se cumplen dos condiciones a la vez: su página de nivel superior debe permitir la función para el origen de ese marco en su Permissions-Policy, y el iframe en sí no debe haberla desactivado. Dicho de otro modo, la página padre fija el límite exterior, y nada de lo incrustado puede concederse una función que la página padre haya retenido.",[18,65,66],{},"También existe un control por iframe que funciona junto a la cabecera, el atributo allow en el elemento iframe, por ejemplo un mapa incrustado añadido con un marco cuyo atributo allow permite geolocation. El modelo mental que conviene retener es que la cabecera es la política a nivel de sitio y el atributo allow es la excepción por incrustación dentro de ella: el marco solo puede recibir lo que la cabecera ya permite, y el atributo luego lo restringe o lo dirige a esa incrustación concreta. Por eso exactamente un widget de terceros a veces informa de que una función está bloqueada aunque el código del widget sea correcto, porque la página contenedora nunca permitió esa función para el origen del widget.",[22,68,70],{"id":69},"qué-ocurre-si-no-la-configura","¿Qué ocurre si no la configura?",[18,72,73],{},"Sin la cabecera, cada función recurre a su propia lista de permitidos predeterminada, que para varias funciones es más permisiva de lo que un sitio típico necesita. En la práctica eso significa que capacidades que nunca usa siguen siendo accesibles, y que el contenido de terceros incrustado puede ser capaz de solicitar funciones que no habría concedido si le hubieran preguntado.",[18,75,76],{},"No suele ser un agujero urgente, y por eso queda sin atender, pero es uno real. Importa más donde incrusta código que no escribió: una etiqueta de analítica, un widget de chat, un píxel de marketing. Restringir las funciones que no usa reduce lo que todo ese código incrustado puede intentar, y es exactamente el tipo de cabecera ausente que los escáneres de seguridad y las auditorías señalan ahora en casi todos los sitios que no la han configurado.",[22,78,80],{"id":79},"cómo-se-implementa-la-cabecera-permissions-policy","¿Cómo se implementa la cabecera Permissions-Policy?",[18,82,83],{},"Configura Permissions-Policy como una única cabecera de respuesta HTTP. Una política de partida sensata es desactivar las funciones que sabe que no usa y limitar el resto a su propio origen, por ejemplo Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), y luego relajar directivas individuales solo donde exista una necesidad real. Puede aplicarse en el servidor web, en la capa de aplicación, o en el borde en un CDN o una capa de seguridad situada delante del sitio.",[18,85,86],{},"Ayuda verlo contra un sitio real en lugar de en abstracto. Tome un sitio de clínica que muestra un mapa incrustado para que los pacientes encuentren la consulta, y ejecuta una herramienta de reservas en línea que abre un paso de pago, pero no tiene ningún otro uso de las funciones del navegador. Una política adaptada a ese sitio desactivaría todo lo que nunca toca y solo permitiría lo que esas dos funciones necesitan: geolocation limitada al origen del proveedor del mapa, payment limitado al proveedor de reservas o pago, y cámara, micrófono y los distintos sensores todos desactivados con una lista de permitidos vacía. El resultado es una página donde el mapa y el pago funcionan exactamente como antes, mientras que cualquier otra capacidad simplemente no está disponible para ningún script, sea suyo o de un tercero incrustado. El principio se generaliza: enumere lo que el sitio usa de verdad, permítalo a los orígenes concretos que lo proporcionan, y cierre el resto.",[18,88,89],{},"Pruebe antes de bloquearla. La cabecera tiene un compañero report-only, Permissions-Policy-Report-Only, que usa la Reporting API del navegador para indicarle qué bloquearía una política sin aplicarla realmente. Ejecutarlo primero es la forma segura de descubrir si una función real, un mapa que necesita geolocation, una herramienta de reservas que abre un flujo de pago, un vídeo incrustado, quedaría atrapada por su política, de modo que la permita deliberadamente en lugar de romperla por sorpresa.",[22,91,93],{"id":92},"qué-cambia-en-su-sitio-una-vez-activada","¿Qué cambia en su sitio una vez activada?",[18,95,96],{},"Para la mayoría de los sitios, nada visible. Las páginas ordinarias que no usan funciones restringidas se comportan exactamente como antes, y los visitantes no notan nada, porque la política solo interviene cuando algún código intenta acceder a una función que no ha permitido.",[18,98,99],{},"El punto que conviene revisar es cualquier función de la que su propio sitio dependa de verdad, y cualquier cosa que necesiten sus terceros incrustados. Un localizador de tiendas que usa geolocation, una función de videollamada que usa cámara y micrófono, o un pago que usa la API de pago deben tener todos sus directivas configuradas para permitir los orígenes correctos, que es precisamente por lo que la prueba en report-only importa antes de la aplicación. Acierte con eso una vez y la cabecera mantiene después la línea en silencio, permitiendo lo que pretendía y rechazando todo lo demás.",[22,101,103],{"id":102},"qué-debería-hacer-a-continuación","¿Qué debería hacer a continuación?",[18,105,106],{},"Empiece por comprobar si su sitio envía siquiera una cabecera Permissions-Policy, ya que sin ella cada función recurre simplemente a su valor predeterminado. Si falta, la vía de bajo riesgo es añadirla en modo report-only, enumerar las funciones que realmente usa, confirmar que nada de lo que depende se bloquea, y luego aplicar una política que desactive todo lo demás.",[18,108,109,110],{},"Si desea que esto se revise y configure correctamente en todo su sitio en lugar de pieza por pieza, EuroraCloud puede comprobar sus cabeceras de seguridad actuales y mostrarle qué resuelve nuestra plataforma. ",[40,111,114],{"href":112,"rel":113},"https:\u002F\u002Fwww.euroracloud.eu\u002F",[44],"Vea qué resuelve EuroraCloud",[22,116,118],{"id":117},"conclusión-qué-debería-retener-sobre-la-cabecera-permissions-policy","Conclusión: ¿qué debería retener sobre la cabecera Permissions-Policy?",[18,120,121],{},"Permissions-Policy es una cabecera silenciosa y práctica: le permite desactivar las funciones del navegador que su sitio nunca usa y limitar las que sí usa solo a los orígenes que las necesitan, de modo que ni sus propios scripts ni los terceros incrustados puedan acceder a capacidades que nunca tuvo intención de exponer. La forma segura de adoptarla es probar en modo report-only, confirmar que sus funciones reales siguen funcionando, y luego aplicar una política que desactive el resto. El paso más útil es comprobar si su sitio envía la cabecera hoy, porque mientras no lo haga, cada función queda en su valor predeterminado.",{"title":123,"searchDepth":124,"depth":124,"links":125},"",2,[126,127,128,129,130,131,132,133],{"id":24,"depth":124,"text":25},{"id":34,"depth":124,"text":35},{"id":59,"depth":124,"text":60},{"id":69,"depth":124,"text":70},{"id":79,"depth":124,"text":80},{"id":92,"depth":124,"text":93},{"id":102,"depth":124,"text":103},{"id":117,"depth":124,"text":118},"Cabeceras de seguridad","2026-07-13","La cabecera Permissions-Policy permite a un sitio decidir qué funciones del navegador, como la cámara, el micrófono y la geolocalización, pueden usar sus propias páginas y el contenido incrustado. Esto es lo que hace, cómo configurarla y qué cambia cuando lo hace.","md",[139,141,143,146,149,151,154,157],{"question":25,"answer":140},"Los navegadores modernos exponen capacidades potentes como ubicación, cámara, micrófono y sensores de movimiento, y cualquier script en su página, incluido código de terceros incrustado, puede en principio pedir usarlas. Permissions-Policy existe para que pueda declarar a nivel de sitio qué funciones están permitidas y para quién, cerrando la brecha entre lo que un navegador puede hacer y lo que su sitio necesita. Cuando una política bloquea una función ni siquiera se pide al usuario y el intento de un script simplemente falla.",{"question":35,"answer":142},"La cabecera es una lista de directivas, una por función, cada una con una lista de permitidos de orígenes que pueden usarla. La sintaxis es el nombre de la función, un signo de igual, y los orígenes permitidos entre paréntesis, con directivas separadas por comas, por ejemplo geolocation=(), camera=(self). Una lista vacía () desactiva la función en todas partes, self solo permite su propio origen, un origen específico permite ese origen, y * la permite en todas partes. Cada función tiene además una lista predeterminada de *, self o ninguno que se aplica cuando no dice nada.",{"question":144,"answer":145},"¿Cómo se comporta la cabecera Permissions-Policy con los iframes incrustados?","Una función solo está disponible dentro de un iframe incrustado si se cumplen dos condiciones a la vez: su página de nivel superior debe permitir la función para el origen de ese marco, y el iframe en sí no debe haberla desactivado. La página padre fija el límite exterior y nada incrustado puede concederse una función que la página padre haya retenido. El atributo allow en el elemento iframe funciona además como excepción por incrustación: el marco solo puede recibir lo que la cabecera ya permite.",{"question":147,"answer":148},"¿Qué ocurre si no configura la cabecera Permissions-Policy?","Sin la cabecera, cada función recurre a su propia lista de permitidos predeterminada, más permisiva de lo que un sitio típico necesita para varias funciones. Capacidades que nunca usa siguen siendo accesibles, y el contenido de terceros incrustado puede solicitar funciones que no habría concedido. Rara vez es urgente, y por eso queda sin atender, pero importa más donde incrusta código que no escribió, como una etiqueta de analítica, un widget de chat o un píxel de marketing, y los escáneres lo señalan ahora en casi todos los sitios que no la han configurado.",{"question":80,"answer":150},"Configure Permissions-Policy como una única cabecera de respuesta HTTP, en el servidor web, en la capa de aplicación o en el borde. Una política de partida sensata desactiva las funciones que no usa y limita el resto a su propio origen, por ejemplo geolocation=(), camera=(), microphone=(), payment=(). Pruebe primero con el compañero report-only, Permissions-Policy-Report-Only, que usa la Reporting API del navegador para indicar qué bloquearía una política sin aplicarla, de modo que permita las funciones reales deliberadamente en lugar de romperlas por sorpresa.",{"question":152,"answer":153},"¿Qué cambia en su sitio una vez activada la cabecera Permissions-Policy?","Para la mayoría de los sitios no cambia nada visible, porque la política solo interviene cuando algún código intenta acceder a una función que no ha permitido. El punto que conviene revisar es cualquier función de la que su sitio dependa y cualquier cosa que necesiten sus terceros incrustados, como un localizador de tiendas con geolocation, una función de vídeo con cámara y micrófono, o un pago con la API de pago, que deben tener todos sus directivas configuradas para permitir los orígenes correctos. Por eso la prueba en report-only importa antes de la aplicación.",{"question":155,"answer":156},"¿Qué debería hacer a continuación respecto a la cabecera Permissions-Policy?","Compruebe si su sitio envía una cabecera Permissions-Policy, ya que sin ella cada función recurre a su valor predeterminado. Si falta, añádala en modo report-only, enumere las funciones que realmente usa, confirme que nada de lo que depende se bloquea, y luego aplique una política que desactive todo lo demás.",{"question":158,"answer":159},"¿Qué debería retener sobre la cabecera Permissions-Policy?","Permissions-Policy le permite desactivar las funciones del navegador que su sitio nunca usa y limitar las que sí usa solo a los orígenes que las necesitan, de modo que ni sus propios scripts ni los terceros incrustados puedan acceder a capacidades que nunca tuvo intención de exponer. La forma segura de adoptarla es probar en modo report-only, confirmar que sus funciones reales siguen funcionando, y luego aplicar una política que desactive el resto. El paso más útil es comprobar si su sitio envía la cabecera hoy, porque mientras no lo haga, cada función queda en su valor predeterminado.",{},true,"\u002Fblog\u002Fes\u002Fwhat-is-permissions-policy","8 minutos",{"title":8,"description":136},"what-is-permissions-policy","blog\u002Fes\u002Fwhat-is-permissions-policy",[168,134,169,4],"Permissions-Policy","Seguridad web","jWcct9a1ILm6_uy-8vXHotPnsMHz2voBsJWiEzEeUd8",1785141133376]