What are the risks of having an unsecured api, if there's nothing sensitive in the database?

Question

I understand that the answer is probably that ideally, I would just have a secured api, but I want to understand the threats that exist as well as the defenses. And all of the articles I've read focus primarily on "they could come in and take your data," which just isn't my problem. Say for example:

• I have an api that I call from a separately hosted frontend
• This client-side app is authenticated with a separate service, giving me the user's email
• I use the email (or an obfuscated version of it) in a call to the api, to identify the user
• The api's database only holds the obfuscated email of the user, and the words that user has learned (this is a language-learning website).

My question is, What are the risks? I understand this single question is likely too vague to be particularly helpful, or even capable of being answered, so I would like clarify what I understand might be risks.

1. I do not think hackers care about just raw email addresses, unconnected to other information, but this might be wrong.
2. I realize that in theory, somebody could do something like make a million calls to my database for fun, and -- pretend they'd learned a lot of words, or create a lot of users, but I don't think they would, realistically, since I imagine this would take some effort, for no value.
3. I obviously understand that if this database were to hold credit card information, or medical records or something, this would be unacceptable. But because it doesn't -- how real are the other risks?

Answer 1

You don't really provide information about the actual capabilities of the API, only what the database behind the API kind of contains. Your question is based on the assumption that these information are not sensitive and that there is no value in (mis)using the API outside of your application - but at the same time you are questioning these assumptions.

Looks like what is missing here is a proper risk analysis which looks at the actual details, but for this not enough information are available (and would be out of scope anyway). But lets help with getting the approach in the right direction, so you might be able to do some analysis yourself based on your deeper knowledge of the data and API.

As for nothing sensitive: Since the details of the API are not known I can only make assumption on what information it might provide. It might for example give an attacker a way to detect that someone uses your service in the first place. It might also be interesting that some users were active at specific times. And maybe also the IP address they used can be retrieved, which then can be associated with location information. And from how long they needed to learn specific words information might be gained about their state of mind at specific times. Just to illustrate some unintended side effects of collected and publicly available information read Fitness tracking app Strava gives away location of secret US army bases.

As for attacks providing no value: There might be a business model behind your application. Simply disrupting this could actually be a value for some competitor. Also, maybe your API has bugs so that it can be used to execute code on the server side and then attack other systems? Don't just assume that your API will be used the way you've intended, but imagine how it can be misused in an unintended way.

Answer 2

Even if your database doesn't hold sensitive data, you still need to have a secure API, the privacy of your users is on the stake, and if confidentiality doesn't worry you; think of integrity and availability (CIA triad).

I realize that in theory, somebody could do something like make a million calls to my database for fun..

A million call in a short time could cause a denial of service, which results in the unavailability of your API service. There is also a risk on the database's integrity, the learned words for some users could be changed from unauthorized API calls, how important is this ? only you can bring an answer.