Yes, this is a nice solution, but email security services do click on links before delivering to the client's email inbox. As such, you may need to set the link expiry click number to greater than 1. And then you lose the security due to being ephemeral. Of course, you can log the IP addresses of the clickers, but still you have the leak.

> email security services do click on links before delivering to the client's email inbox

True. This may be a problem. Like mentioned, common bots are being blocked currently, plus, I will be testing POST instead of GET requests (Since bots apparently don't do POST). An another obvious solution is to include some kind of user interaction before the secret is fetched. Although I don't like that solution so much. C.

In practice this has not been a problem. It's like saying you can't put unsubscribe links in emails because a bot will click on it... You just simply design the software so that doesn't happen.

Like I said, I've used a similar service that only allows you to view the secret once and I've used it dozens of times with no problems.

> you just simply design the software so that doesn't happen.

How do you go about doing that? disregard security service clicks based on IP address blacklists, user agent sniffing, etc?

Nope you just use a POST request...

How does a legitimate user clicking on a link inside an email generate a POST request?

It loads a page which then makes a POST request to an API via JS.

Thanks again for all the feedback. Short update: I'm using DELETE now, since it feels a bit more accurate. As a side effect, the page is way more responsive. :)

Have fun sharing secrets. C.