Replies: 2 comments 2 replies
-
Protect from what exactly? I think the answer may depend on what that answer is. If you're simply talking about authenticating requests, then I'd still use a standard JWT (issued by your auth service/Worker) with short expiry, held on to by the client to send with requests. The authenticated API would have a blanket "validate token to authenticate user" upstream, and downstream services could check if there's a valid user attached to the Request. If you're talking about preventing people from even hitting your Worker service in the first place (maybe to keep costs down), or preventing like a DDoS, then this isn't your answer - and I'll leave that to the folks that know how to protect against that sort of thing on CF. I'm assuming there are rules to find within the dash for that? |
Beta Was this translation helpful? Give feedback.
-
If you discover a good solution to the latter, please update here! That would be good info for us all to have! :) |
Beta Was this translation helpful? Give feedback.
-
I'm curious how people here protect their Cloudflare Workers when these workers are requested by a browser within an app? Is there any way? Server to server is easy, as you can send a authorization header or sign the URL per Workers docs and the secrets are hidden from the browser, but how do you do that if you are calling the Worker endpoint in the browser? CORS is not really security per se, as anyone can use something like postman to get around cors. The option of signing the URL or sending in an header key is also not secure in the browser, as by definition the keys will be exposed in some way in the browser. So what's the solution? My only solution, thus far, has been to "proxy" my browser requests to Workers thru a server and sign them on the server, but this kind of defeats the purpose of Workers as the proxying thru the server slows the request down.
Thanks
Beta Was this translation helpful? Give feedback.
All reactions