Security Headers

[TracySchloss]

All the ESRI examples are always very straight forward, but simple and plain when it comes to headers.  In today's world we're asked to tighten down our code with the introduction of many more security headers.  This is is not my area of expertise, I'm always doing good to get my code to work!  It's my understanding some configuration can happen on the application server, as an overall configuration, while others are best managed per application.

Given that I'm referencing the JavaScript API from ESRI, and not locally hosting it, coupled by the fact that we're pulling data in as services from sites outside our network, it's not as if I this can be configured based on examples provided to us from our cybersecurity 'best practice'.  There's no point in tightening it down to be non-functioning.

These are the header I'm being asked about.  There may be others as time goes on:

HTTP Public Key Pinning (HPKP) Header 

HTTP Strict Transport Security (HSTS) Header

X-XSS-Protection Header

X-Frame-Options Header Header 

X Permitted Cross Domain Policies Header 

Content-Security-Policy (CSP) Header 

X-Content-Type-Options Header 

Referrer-Policy HTTP header

Does anyone have any examples, words of wisdom?  I know people are likely to send me links to sites about what these are.  That's not what I want.  I have someone who can tell me generally what each is for.  What I want is syntax for settings that are likely to work.  The goal is to be more secure, but still functioning.  I've been told that implementing a CSP Header\, for example, could result in the inability to access the JavaScript API library, which is full of Function ().

[RandallWilliams]

Where are your apps hosted? These are all set at the web server tier. Implementing these depends on the web server.

HTTP Public Key Pinning (HPKP) Header 

I've personally never had anyone ask about HPKP. This feature helps if a Certificate Authority were somehow compromised, an attacker could potentially present those certs to users via an intercepting proxy, and a user wouldn't get a warning in the browser. 

HTTP Strict Transport Security (HSTS) Header

I implement this header on my servers. It'll be supported OOTB in a near future version of ArcGIS Server. If a site has HSTS enabled, after the first visit to the site, all subsequent visits will be forced over HTTPS. There's also an option for HSTS preloading that will force even the first visit to a site to be over HTTPS, but the browser has to know ahead of time that the site is HSTS enabled and advertises preload.

X-Frame-Options Header

This header specifies whether a website can be rendered in a frame. Frames can be used to steal input into a site. Setting this header value to SAMEORIGIN means that the page rendered in a frame or other object comes from the same origin/server as the site in a frame. Other options are 'ALLOW' and 'DENY'. This header should always be set when there's a login form. Depending on the data you're collecting through a form, you may want to set this on other locations. We purposefully don't set this on the ArcGIS Online map viewer, since it's meant to be framed. 

X Permitted Cross Domain Policies Header 

There's a couple ways to implement this. These days, this is typically 'Access-Control-Allow-Origin', or CORS. This specifies from which hosts JS apps can submit POST requests. This has value for feature access edits or apps that consume GP services. 

Content-Security-Policy (CSP) Header 

Specifies from where executable content can be loaded from. Helps prevent Cross Site Scripting (XSS).

X-Content-Type-Options Header (AKA NOSNIFF)

This prevents MIME type spoofing. We're working on supporting it - this requires significant changes on our end. If you set this at the web tier you'll likely break your apps because they're all expecting a specific mime type. 

Referrer-Policy HTTP header

This one's pretty new. It prevents referrer spoofing. Auth headers often depend on the referrer field. Some providers only allow content to be loaded on specific websites. This header prevents that. Referer spoofing - Wikipedia 

[MarceloRosensaft]

Hello @RandallWilliams 

Regarding the header "X-Content-Type-Options Header", you wrote that Esri is working on it. Are there any news about it?

Thank you in advance,

Marcelo

[randoodlydingdangdodlyWilliams]

X-Content-Type-Options: NOSNIFF has been supported since10.7. https://enterprise.arcgis.com/en/server/10.7/administer/windows/disable-the-no-sniff-header.htm

[TracySchloss]

We're still "all in one" on our ArcGIS Server box, as opposed to separate web servers, but that will change when we upgrade to 10.6 in a few months. 

This is helpful, thank you. These headers in particular come from: https://tools.geekflare.com/header-security-test  Our current applications don't have most of these set, so our ESRI JavaScript applications are considered a fail.  ArcGIS Online has a similar score using an AGOL application!

Our state's cyber security group is on the leading edge for state government, locking down our servers as much as possible as our "new normal".   We're being told "you have to set all these", but I expect them to back down a bit once they realize how many other applications, not just ESRI, is going to be broken.

[RandallWilliams]

Sometimes it doesn't make sense to set these headers. For instance, you won't see CORS headers on ArcGIS Online basemap servers because there's no way to proactively know from where an application that consumes our services may be hosted - plus, those are just images, typically retrieved via a GET instead of a POST, and users won't be editing those. ArcGIS Online Org admins do have the ability to define allowed origins for their hosted services. By default Esri doesn't set these - again, we don't know who you'll allow to consume services you publish ahead of time.

Configure security settings—ArcGIS Online Help | ArcGIS 

Context is key. A heavy handed approach by IT staff that lacks context won't work well. 

[RandallWilliams]

Since I'm thinking about it, and while it's a little informal (I wrote this as a blog for an internal audience), here's some detail on CORS headers specifically that I like to send to folks to help provide context:

CORS and ArcGIS Enterprise

I frequently have the opportunity to review and comment on automated security scans organizations perform against their ArcGIS Enterprise instances. A point of confusion I see is regarding 'Insecure CORS Configuration', which some tools flag as a 'HIGH' priority finding.

In general, context is key when examining security related findings, and a 'finding' is relative to the intent of the application. 

Background:

CORS (Cross Origin Resource Sharing) is used in *JavaScript* applications when making POST requests to Feature of GP Services on a different server.  CORS is not the only way to make cross domain requests. If a web application is just used for viewing a map service, CORS isn't used.

In context, CORS requests are used when editing feature services or submitting a job to a GP Service. CORS is enforced either at the client tier or via the web browser.

By Cross-Origin, what is meant is that if a web service and a web application are hosted on the same machine, no Origin Crossing happens.

If a web service is hosted on machine A and a JavaScript web application that consumes a service is on machine B (Crossing Origins), and clients interact with a Feature Service/GP Service via Post requests, machine B's FQDN must be configured in machine A's 'Allowed Origins'.

Restricting Cross-Domain requests does not restrict overall access to web services (that's what securing the service does) - restricting CORS headers is a layer of protection in a defense-in-depth strategy.

By default ArcGIS Server and Portal for ArcGIS sets the Access-Control-Allow-Origin header to '*' (allowing all origins), because by default ArcGIS has no way of knowing from which domain web services will be consumed prior to installation.

This default configuration is what the automated tool flags.

Detail:

In many use cases (let's use Facebook as an example), there will be only one application consuming web services - Facebook.com. In this case, it makes sense to limit allowed origins to one domain - Facebook.com. However, if an Esri customer wants to configure Allowed Origins, the admin must know from where a given web app will be hosted. In many cases, this will be easy. Other times, it may not be possible to know from which domain an app that consumes services may be hosted. This all depends on the intent of the web service.

With ArcGIS Server, domains must be explicitly specified in a comma separated list. Wildcards are not supported. Best form is to use the FQDN format, like https://host.domain.com.

Starting at 10.6, we introduced the ability to set CORS origins in Portal for ArcGIS via the Portal Home Application. At previous versions, allowed origins can be set in the Portal Sharing API.

Allowed CORS origins can also be defined at the web tier. See: https://enable-cors.org – be careful though, if the same allowed origin is defined twice, the app may decline to consume the web service.

In Portal's case, CORS allowed origins applies to Portal items or resources instead of GIS Services. Wildcards are supported Portal-side.

TL;DR:

Restricting Cross-Domain requests does not restrict overall access to web services (that's what securing the service does) - restricting CORS headers is a layer of protection in a defense in depth strategy that restricts how JS apps interact with web services depending on the origin of the request.

Proper context and framing is required to verify the severity of a given finding discovered by an automated scanner.

[AndrewMurdoch1]

I love this opinion, and you're absolutely right that context, and situational awareness is key!   Far too often a tool will point out you're missing setting (or header), X, Y and Z, when X, Y and Z aren't actually useful or productive.   A good example is setting a CSP header!  CSP headers are very important when you have to strictly lock down where resources can load from, which for a bank is vital, but for most applications, isn't a good idea.


If anyone suggests you need to lock down everything down like it's a high security, mission-critical vault, then ask why? In almost all cases they want things locked down so they can have "green A" show up, or so the report can list you have X, or Y, when in reality neither matter.

Spending 20 extra hours to move from a B to an A, on a tool that doesn't understand context, only wasted 20 hours, unless you can defend putting the work in beforehand.  People will generally spend X hours locking down everything, like it's a 100-foot thick concrete reinforced super max prison, without first taking the broken screen door off the front, that was the problem all along.