fp.

Great piece, but worth mentioning that you generally can't use a presigned URL with CDN endpoints. So great for sensitive content, but if you rly want the thing to be widely and quickly accessible there's more work to be done

inopinatus•2m ago

Well, you can if the signed URL is signed for the CDN's verification instead of the underlying storage.

Generalising this: you don't need stateful logged-in authentication to defeat IDOR, you can include a system-specific HMAC in the construction of a shared identifier, optionally incorporating time or other scoping semantics as necessary.

This tends to make identifiers somewhat longer but still well inside the scope of an email'd URL to download your bill without having to dig up what your telco password was.

ronbenton•16m ago

I am a bit "meh" on the YouTube "unlisted video" example. The name itself is fairly transparent in implying that there's really no security, the video is just not listed in a public-facing way. This is significantly different than the article's billing example, where customers would be quite right in assuming their bills will be only accessible to them.

shoo•11m ago

> If you use secret UUIDs, think of them as toxic assets. They taint anything they touch. If they end up in logs, then logs must be kept secret. If they end up in URLs, then browser history must be kept secret. This is no small challenge.

a fun retail banking variation of this misadventure is (1) someone designs an elegant RESTful API for doing something or other (2) and it gets applied to credit cards, where the credit card number is used as the natural primary key and is RESTfully embedded in URLs, which people endeavour to avoid logging, but then when you (3) integrate middleware to report metrics to some SaaS monitoring platform, the end result is that you're spraying all your customers credit card numbers into the monitoring platform