which browser security features do you find the hardest to use correctly?

very interested in "other" responses too, I could only include 4 options in the poll

@b0rk CSP is probably the hardest to remember all the flags for, but I wouldn't say any of them are hard to use. but I'm probably not an ideal respondent on that front because, y'know, literally my job to know this stuff inside and out. (I didn't vote for that reason)

@gsuberland it feels weird to me because (as a very non-expert) on one hand it feels like CORS is sort of straightforward, but on the other hand if someone asked me to explain the difference between a "site" and an "origin" and what the implications of that are I absolutely could not do it in a way I'd find satisfying

@b0rk yeah, I think I'd say the root of the complexity is SOP itself rather than CORS, since CORS is a mechanism to manipulate exceptions to SOP and the actual mechanism isn't all that complicated. technically this applies to CSP, too, since that also alters SOP for various resource types.

but knowing how SOP behaves in order to decide what CORS/CSP rules need to be applied definitely isn't straightforward once you get out of the most basic use-cases.

@b0rk CSP is likely the most annoying, as it's often a process of trial and error when adding one, trying to find everything that should be included. I wouldn't call it hard, though I don't think I've ever added one in less than 2 deployments, due to missing something on the first try.

All of them are a bit complicated in their own ways, though they are doing a complicated job, so I would see that as expected.

I should note that I've taught these topics in developer training classes, so I'm likely not a useful indicator.

@b0rk subdomains are the area where I think a lot of people get confused. like, does a rule for foo.example.com also apply to bar.foo.example.com? even I have to stop and think about that sometimes.

@b0rk @gsuberland They are only "hard" when you have marketing telling you that they NEED to have this external companies stuff running on your site. And then another marketing thing and another. Same for SPF/DKIM, easy when self/single-hosted, hard when marketing overrides technical decisions.

The tracking, that makes it hard. Otherwise a simple same origin policy for your site, hosted on your own server(s).

@b0rk @jeroen there are other cases, like microservice architectures where the frontend service is functionally static and instead makes requests to API services on a separate domain (still operated by the same company) via fetch/XHR. similar stuff for SSO authentication provider integrations. not really relevant for your own toy site, but if you're building stuff at work it does come up a bunch.

@b0rk @jeroen but yeah, ads and tracking are a huge use-case unfortunately :(

@gsuberland @b0rk Agree; those things do pop up. But those are pretty static and you know what the other thing is. It tends to also not cause any risk exposure for your own service; while most marketing tools often import a lot of code ;)

@b0rk @jeroen yeah, true. a lot of that ad code hinges on you massively loosening the CSP from what you could otherwise lock it down to.

@b0rk @jeroen I actually saw an app put ads in a frame for this reason the other day. CSP locked down hard on the main domain, then loosened in the domain used to host the ad frame. kinda surprised that the ad host was ok with that.

it reminded me of PCI DSS compliant payment flows from back in the day.

@b0rk it is my strong held belief that CORS cannot be used correctly.

@b0rk @raven667 What even *are* these?

@b0rk

Whichever one of these disallows me from from viewing HTML files that are on my hard drive without standing up a https webserver first.

@ali1234 i can never remember when that's allowed and when it isn't

@b0rk I think this is because CSP and CORS require a somewhat deep understanding of the application. With cookies, it is usually quite clear if something is a session cookie and then slap HttpOnly/Secure on it