What simple security considerations can I / should I make for a read-only API?

Question

Right now I'm setting up an API, to be consumed on the client-side to set up a directory site. I'm wondering what extra steps I need to take just to prevent people from gaining write access to the data.

Some notes:

• The API / database has no private information. All information is available and none of it is PII etc. It wouldn't be a problem for me if someone read all the data.
• Currently the API is a Sinatra app and it does have write methods so I can add data, protected by HTTP Auth.
• It will be hosted on Heroku and served via HTTPS only.
• The data will not change frequently.
• The data will be backed up on a regular basis so even a destructive break-in wouldn't be the worst thing in the world.

My questions:

• Are there specific areas I should read up about security-wise in this situation?
• Would moving the API write methods (and admin) to a completely different app and then simply syncing the database handle most security issues?
• Is HTTP Auth sufficiently secure with a long username and password or is there a better method than HTTP Auth for authorizing myself in the admin?

(Note: I have looked for related questions and found this: Is BASIC-Auth secure if done over HTTPS? but it's not really clear if there's a better option or method that doesn't open up even more security implications)

• Any other tips or thoughts?

I'm a bit out of my element currently and I want to get this project shipped, rather than lingering too long. I'm sure there's no replacement for proper application security training but I'm hoping because of the public nature of the data, I can ignore a majority of security situations to start and spend more time learning about them later.

Cheers, Anders

Answer 1

Essentially you just need to run through the standard OWASP Top 10 and focus on getting the access control stuff right.

As far as authentication goes, basic auth should be avoided for a number of reasons. It's ugly, insecure, and isn't universally supported. The standard model is to provide users with a randomly generated API key that is separate from their normal login credentials. This allows for reasonable authentication without the risk of having credentials stolen. Regardless, I still recommend HTTPS across the entire API, and it looks like you're already doing this.

Answer 2

Splitting the APIs is really the best option, since the public site only needs to be read-only, there's no reason for the write APIs to live on it. That also would give you the ability to implement additional restrictions more easily, like restricting the IP addresses that can access the admin site.

Failing that, using an API Key as Polynomial mentioned or a session token for accessing the APIs is next best option, as it allows you to call the APIs without having to send credentials with each request, which is potentially more secure.

However, it sounds like the security concerns you have around your application are fairly minimal and minor, so I'd say that basic auth with a sufficiently strong password and HTTPS might well be a perfectly acceptable initial implementation. Given that you're the only one who'll be writing to the site, I don't know that I agree with Polynomial's concerns about ugliness, or the the lack of universal support.

The insecurity issues around basic auth were covered in AviD's post you referenced, and if you wanted to mitigate those, you could implement a Sinatra-based auth module like Warden instead of using basic auth.

Answer 3

This question is too broad to be answered. To be honest, it just feels that you're asking someone to do your job for you. Having that said, I'll try to answer you in the best way possible. First thing you need to do is to take care of the OWASP Top 10 List. Pay close attention to injection vulnerabilities and session management.

After that, make sure the database user utilized by the public side of your API has read-only access to the database.

As for HTTP basic authentication, I don't think it carries a huge security risk in your case as long as you're using HTTPS. Since only admins will need to authenticate, no need to overcomplicate the process with API keys.

Answer 4

My approach for verify security APIs is to design security functional tests that verifies the robustness of the system. Test top 10 OWASP is fine for verify you are not vulnerable to attacks but I think is more important before to release your service that the expose API is clear, do what should do, cache the information that should cache and so on.