Docs for "securing endpoints"

[stevekrouse]

We're in the business of letting users expose endpoints that call our to other API that they pay for. The whole point of running code to APIs with API keys on a server is that it's secure. However once you expose that endpoint to the world so that you can call it, what's to prevent the whole world from calling it?

For example, one of our best users is using us to wrap a API thing inside of a form, ie as you fill out the form, based on your zip code, it does some calculation. However he's terrified of a surprise crazy bill from the API because someone discovered his endpoint and abuses it. It's a good point! Right now it's really just security by obfuscation. Anyone could get free access to that API if they find it. What's the point of using Val Town even? He could almost put his API token right on the frontend!

So we could answer those questions:

• Why putting your token on val town is better
• How to set a rate limit, maybe with https://www.val.town/v/rlimit/ratelimit
• How to get notifications if usage spikes
• How to get notifications if usage is different / suspsicious
• How to only allow certain kinds of usage
• How to only allow users of your website to do it CSRF token or something? Cloudflare new capcha thing?
• How to create api tokens for their own (possibly paying) users - maybe unkey?

We could really crush the SEO on this too and make this a wonderful evergreen resource. I bet folks are googling for this sort of thing all the time. We just need to figure out the right keywords.

[stevekrouse]

More context: https://discord.com/channels/1020432421243592714/1020432421243592717/1172197816744026204

[stevekrouse]

From @tmcw

If you have an application with users who authenticate to our application, and you want to drive part of that application with Val Town, the things that come to mind are:

JWT tokens
If your app uses JWT tokens, you could theoretically set your JWT secret in your Val Town environment variables, which would allow us to decode JWT tokens that come with requests and verify your users sessions. This would require you pass the JWT tokens explicitly from the form or request - cookies for your application won't be sent with arbitrary requests to other domains.

Host referrer
In an ideal world, you could check the referrer of the request and only allow front-end requests with a proper referrer to succeed – so if the request isn't coming from your.app.com, it'll get rejected.

Unfortunately, because of bad actors, referrers are kind of unreliable - I think that Safari gets rid of the path name and censors referrers, and some proxies might drop them entirely. You might get some false negatives if you filter by referrer.

[karfau]

As soon as you find a way to serve the val from your own domain, the whole thing gets way simpler, since you get those cookies, and can block any access without cookies.

I guess that it already possible using cloudflare or some other tools, but didn't I hear somebody say your are working on integrating that into valtown?

[stevekrouse]

How do custom domains help you manage cookies? Wouldn't you still need to manage them in your code manually yourself? Or does Cloudflare somehow do this for you automatically for certain kinds of protection?

[karfau]

I'm aware that cloudflare access set's a cookie which is a jwt token.
The identity provider it connects to is able to add some information to the cookie.
we use that at work.

And also we were talking about "seccuring endoints", right, so if you have a custom domain that you can reach your val endpoint from, the endpoint would receive any properly configured cookie (*.domain.tldr) of the domain that hosts the frontend (could be the same, if vals also render the frontend)

[stevekrouse]

Yeah I think I understand. That makes sense

[stevekrouse]

Questions from @Xkonti:

The things discussed above protects a resource within a val but not the val user's limit of 10 or 100 runs per minute. Should we also come up with a way to protect that?

Exploiting a user's runs per minute hasn't happened yet and might not happen for a while. We can list it as a potential thing to worry about and assure users that it's unlikely and that if it happens they are not liable for it, and we will work with them to mitigate it if it happens. We also have cloudflare in front of all of our services which should mitigate a lot of similar such attacks

Is this a single large document or a collection of smaller documents?

I imagine it as a main document that links out to other smaller ones. It could start as a single document and grow into a folder. This is a pattern we've already seen in our docs.