As the title suggests, I would like to expose a couple of read-only endpoints without requiring a key or token. The endpoints will allow the user to request their data for the purposes of displaying it on their website.

The reason I am considering this is that I want to avoid the user having to go through the extra work of setting up a separate server to communicate with the API, rather than just making requests from the browser. It seems like this is an okay idea, since the data will be publicly displayed on the user's website anyway.

Then again, I feel like I have some blindspots here that I am missing. Would anyone be willing to poke some holes in this plan?

  • 1
    What is the information that the API is exposing? In your case the information you expose is the information you might lose Feb 25, 2022 at 20:13
  • If you don't put any token, you may suffer resource exhaustion when someone endlessly queries your endpoint, and you cannot do anything. If you do have tokens, you invalidate the attacker's token, solving the issue.
    – ThoriumBR
    Feb 25, 2022 at 20:57
  • I'm curious @ThoriumBR is there a way to just throttle requests coming from a certain address and resolve the issue you mentioned that way? I'm looking into this myself but not finding anything about throttling based on the requesting address.
    – Drew
    Feb 25, 2022 at 23:24
  • @Drew it's called rate limiting Feb 26, 2022 at 15:24
  • @Drew with lots and lots of free proxies around, and IPv6, rate limiting can not be very efficient.
    – ThoriumBR
    Feb 27, 2022 at 0:51

1 Answer 1


It sounds like you are the data controller for user submitted data, i.e you are allowing users to access a system, input data then fetch that later.

You do not describe the type of data you are storing. If I assume this is dynamic user input to your host system, then you are now relying on users not putting any PII there. If they do you will then be in a problematic situation as anyone else can now access this PII publicly.

Even if the above assumptions are incorrect, you might consider first thinking about the data implications. As a data controller/processor you will have legal and regulatory commitments (GDPR for example). If you can be 100% sure the data will always be public and contain no information that could land you or your users in trouble then public consumption of the data might be ok.

Note I say consumption as public access may still be a problem. Access to your system will consume resources. Without any form of authentication you will have to reply on request meta data (IP address etc). This might be enough to let you build appropriate throttling and blocking controls, but only you will know that.

I have no idea of the context of your system, but you may also consider the long term impact of sharing 1 users data with many. Lets imagine for a second this is some form of blog content the user is submitting/retrieving, that content gets a lot of traction, your user loves you and your platform, however unknown to you and your user is someone else is also consuming the same content and hosting it elsewhere, making a profit from someone else’s data.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .