X-Frame-Options: Allow-From do not accept multiple domains and is wrongly written

I'll be amazed if setting multiple values for Allow From actually does what you want it to do, because although the specs are very confusing on the matter, my firm understanding (having investigated this in detail in the past) is that the only way to use Allow From is to set a single value (such that if you need to support multiple values, you must set the correct single value on any given request).

Oh, I see what you're saying. If something has gone awry with the per-line behaviour, the correct response is to fix that. I'll take a look.

Are you using a Mac for site admin by any chance? I can see that the line splitting would handle LF and CRLF EOL styles, but not the CR style that used to be used by Macs. To be honest I thought that OSX had long since deprecated that in favour of the Unix LF style EOLs, but maybe I'm wrong.

Actually, I'm back to suspecting that there is confusion about the spec. To reiterate this:

I'll be amazed if setting multiple values for Allow From actually does what you want it to do

I believe that you're generating a header like:

X-Frame-Options: Allow-From http://domain.com http://example.net

in the hope that this will allow the site to be framed on both of http://domain.com and http://example.net

However that's absolutely not how this header works (or used to work, at any rate).

Refer to https://tools.ietf.org/html/rfc7034#section-2.3.2.3

Can you please confirm whether such a header actually has the desired effect for all listed domains (and still denies access for other domains), and can you list the browsers you have tested it with?

Ok, so FYI it's working as designed.

In accordance with rfc7034 we only output a single Allow-From origin in the header.

As you've noted we do allow multiple values to be entered (one per line), and in that scenario we test the request origin against that list, and when there's a match we output the (single) matching value in the header.

This mechanism works when Drupal's native page caching is used, but if you have a reverse proxy cache in front (such as Varnish) then you would need to take alternative steps to prevent your proxy cache from responding with a cached page with an invalid header for a given request. SecKit can't do anything about such external factors.

I'm very interested in the answers to my comment #7, however.

See also #2675922: frame-ancestors in Content Security Policy and #2779169-11: Allow-From headers are incorrect

Marking as Needs Info (refer to comment 7). Will close as "Works as Designed" if there's no forthcoming information which contradicts my present assumptions.