Hacker News Reader

Comment by simonw | Hacker News Reader

I really like the simplicity of this proposal, and how Adrian compares it to X-Frame-Options: DENY which has been in place for a decade now and has solved the problem of clickjacking and unauthorized framing for regular websites.

My hunch is that having X-Frame-Options: DENY start applying to native mobile apps wouldn't be feasible because it would break too much existing stuff that didn't intend to opt-out of native embedding, but having different syntax (X-Frame-App-Options: DENY for example) would solve this need very effectively.

It's interesting to note that Google have already taken steps in this direction: Google sign-in now detects if it is running in an in-app embedded browser and shows you an error telling you to use the native browser instead: https://developers.googleblog.com/2021/06/upcoming-security-...

View on HN

If a native app has as much control over the webpage as it seems to, I'd be surprised if it's not able to strip the header. Or point through a proxy that strips it, and ignore the ensuing HTTPS errors, or some other workaround.

Yea - in-app browsers are just more code... so Google could modify webkit mobile distros to adhere to this behavior but if Facebook was willing to compile their own library (which, honestly, they probably do already anyways) they would need to voluntarily comply with respecting such headers... right now I think this is do-able, app store controllers have a firm enough grasp on the market they could boot any apps that refuse to play nice - but it will require enforcement efforts.

Another option is to force these browser plugins to be shared objects that the app store has more control over but then you'll wander into the territory of how to enforce it on every fork of firefox and the like.

Editing to add: Oh legacy apps are a huge can of worms here - most businesses don't bother updating out of date app versions so folks with older phones will probably be stuck with perpetually insecure apps. But legacy apps and the "tight" control Google & Apple have are sort of perpetual issues to any sort of security.

Apple actually has really tight quality control over the applications found on the app store. If your app is found to have a vulnerability, it goes away immediately. That is why you don't have apps with malware or apps rooting the device or apps replacing the launcher via an exploit.

Or apps that compete with Apple

Or just straight-up fake the sign in page. There’s no way to tell.

IIRC the [responsible org] says we don't have to add the `X-` to custom headers anymore.

Edit: IETF and IANA are the orgs

RFC 4229 https://www.rfc-editor.org/rfc/rfc4229.html

This is not a custom header (i.e. one with no UA semantics), it is a standardized header called X-Frame-Options which requires the “X-“ for browsers to recognize it. The prefix is an artifact of the era the header was introduced in.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...

It's also been deprecated in favor of the content-security-policy header.

Was curious what they say about it but the link didn't seem to have anything on custom headers.

Reply on news.ycombinator.com