Jason E Bailey commented on SLING-7760:

[~cziegeler] Here's a some of the headers that we currently have. Note that the 
Content-Security-Policy is huge because we have 5 separate domains that we 
serve out of our instances. So any one domain has permissions to source data 
from a domain it doesn't actually interact with because another one of our 
domains requires it.

X-Content-Type-Options: nosniff
X-XSS-Protection: 1;mode=block
X-Frame-Options: sameorigin
Content-Security-Policy: default-src * 'self' data: 'unsafe-inline' 
blob:;script-src * 'self' blob: data: 'unsafe-inline' 'unsafe-eval' 
*.trustarc.com *.doubleclick.net *.liveperson.net *.sas.com assets.adobedtm.com 
ssl.google-analytics.com accdn.lpsnmedia.net www.googletagmanager.com 
www.google-analytics.com bat.bing.com benchtag.co front.facetz.net 
*.facebook.net *.facebook.com www.googleadservices.com tb.juiceadv.com 
*.linkedin.com pixel.mathtag.com pixel.quantserve.com *.quora.com 
analytics.twitter.com tagmanager.google.com mc.yandex.ru static.ads-twitter.com 
snap.licdn.com *.bizographics.com dev.visualwebsiteoptimizer.com 
scripts.demandbase.com consent.truste.com s.yimg.com ssl.gstatic.com 
api.company-target.com script.crazyegg.com platform.twitter.com 
sp.analytics.yahoo.com x.bidswitch.net s7.addthis.com ad4.adfarm1.adition.com 
livestream.co *.brightcove.net track.adform.net insight.adsrvr.org 
www.vintom.com b92.yahoo.co.jp cdn.appdynamics.com 
execution-dscvrtraffic.cidev.sas.us *.brightcove.com *.mrpfd.com d3js.org 
*.d3.org;img-src * 'self' data: *.google-analytics.com *.doubleclick.net 
www.google.com *.sas.com front.facetz.net *.facebook.com 
www.googleadservices.com tb.juiceadv.com ext.ligatus.com bcp.crwdcntrl.net 
pixel.mathtag.com *.quora.com cdn.taboola.com analytics.twitter.com 
d.company-target.com mc.yandex.ru t.co px.ads.linkedin.com *.bizographics.com 
insight.adsrvr.org assets.adobedtm.com *.brightcove.com;font-src * 'self' data: 
*.sas.com fast.fonts.net;connect-src * 'self' *.sas.com *.brightcove.com 
ma156-r.analytics.edgekey.net api.company-target.com livestream.com 
www.vintom.com *.doubleclick.net assets.adobedtm.com;frame-src 'self' 
assets.adobedtm.com lpcdn.lpsnmedia.net *.liveperson.net www.youtube.com 
s7.addthis.com *.twitter.com *.sas.com pixel.mathtag.com livestream.com 
ad4.adfarm1.adition.com www.vintom.com *.doubleclick.net *.facebook.net 
*.twitter.com *.trustarc.com *.facebook.com *.linkedin.com;frame-ancestors 
*.ci360.sas.com *.gatheriq.analytics *.curriculumpathways.com
Cache-Control: max-age=3600

As you can see the Content-Security-Policy is the problem child and could do 
with some sort of tool to assist in it's creation in it's own right.



> Sling Main Servlet - Change header configuration to a service
> -------------------------------------------------------------
>                 Key: SLING-7760
>                 URL: https://issues.apache.org/jira/browse/SLING-7760
>             Project: Sling
>          Issue Type: Improvement
>            Reporter: Jason E Bailey
>            Assignee: Jason E Bailey
>            Priority: Major
> The ability to set headers must be done prior to any writing that occurs the 
> output stream. This is the reason why the headers are set to be configured in 
> the Sling Main Servlet.
> With Sling being used to maintain multiple sites, having a single set of 
> response headers creates problems where the header provides a non tailored 
> response. One site may have a conflicting set of requirements then another 
> site.
> If the setting of headers was moved from being a configuration to being a 
> service used by the Main Servlet, this would allow the following:
>  * Headers set on a per site basis
>  * Headers based on selected resource
>  * Ability to modify the headers without causing the restart of the Sling 
> Main Servlet
>  ** Which if you're dealing with CSP headers can be a constant pain
>  * Ability to create a CSP configuration Service that eases the use of CSP 
> creation

This message was sent by Atlassian Jira

Reply via email to