11–20 of 38 posts
Not sure I agree with this part: > Allow all GET, HEAD, or OPTIONS requests. > These are safe methods, and are assumed not to change state at various layers of the stack already. Plenty of apps violate this assumption and do allow GET requests to alter state.
Not sure I agree with this part: > Allow all GET, HEAD, or OPTIONS requests. > These are safe methods, and are assumed not to change state at various layers of the stack already. Plenty of apps violate this assumption and do allow GET requests to alter state.
IMO apps that do this have a bug, and possibly a security one. This causes issues with prefetching, bot traffic, caching, CSRF, and just plain violates HTTP standards.
i just discovered the Sec-Fetch stuff recently, due to Go 1.25's changelog. Very excited to start using it in some applications where tokens are currently used - what a hassle to deal with those.
Cookies have been truly horrible. I check in on them every couple of years, because I don't do a lot of front-end but when I do it's often security-sensitive, and every single time I check in on them there's some new entry in "SameSite; NoSeriouslySecureHarder; WhoopsTheLastStandardWasNotGoodEnough=BeActuallySecure; AwwShitDidWeGetItRightLastTime=false" parade of attributes you need to send to get actually secure coo…
i just discovered the Sec-Fetch stuff recently, due to Go 1.25's changelog. Very excited to start using it in some applications where tokens are currently used - what a hassle to deal with those.
Cookies have been truly horrible. I check in on them every couple of years, because I don't do a lot of front-end but when I do it's often security-sensitive, and every single time I check in on them there's some new entry in "SameSite; NoSeriouslySecureHarder; WhoopsTheLastStandardWasNotGoodEnough=BeActuallySecure; AwwShitDidWeGetItRightLastTime=false" parade of attributes you need to send to get actually secure coo…
Earlier quoted context omitted.
IMO apps that do this have a bug, and possibly a security one. This causes issues with prefetching, bot traffic, caching, CSRF, and just plain violates HTTP standards.
Agreed. Those methods should be treated as idempotent.
Idempotency still implies it can change state on the initial call, which to me feels wrong in the context of GET/HEAD/OPTIONS.
And if Go is implementing this specific protection, are other ecosystems doing this as well? My specific interest would be .NET/C#, but I am wondering in general how widespread this specific solution is at the moment.
Not sure I agree with this part: > Allow all GET, HEAD, or OPTIONS requests. > These are safe methods, and are assumed not to change state at various layers of the stack already. Plenty of apps violate this assumption and do allow GET requests to alter state.
Earlier quoted context omitted.
Agreed. Those methods should be treated as idempotent.
> Those methods should be treated as idempotent Idempotency still implies it can change state on the initial call, which to me feels wrong in the context of GET/HEAD/OPTIONS.
Not sure I agree with this part: > Allow all GET, HEAD, or OPTIONS requests. > These are safe methods, and are assumed not to change state at various layers of the stack already. Plenty of apps violate this assumption and do allow GET requests to alter state.