How to secure Rails API requests?

Question

I have an API only rails app and another angular app as frontend

Currently I'm securing the API by sending X-APP-Token with each request on headers

The other APIs which has logged in user has X-User-Token on headers as (JWT)

My question here, with each request sent from angular, the token are exposed on headers and anyone can have access to them

How can i secure these tokens from both front-end and back-end perspective? like salting and encrypting so that if someone stole that token, it should be useless

Thanks in advance

Answer 1

In production your client code should be communicating with your backend API with an SSL secured connection. Most of the time you would put an SSL certificate on a web server or load-balancer that is proxying your API or app server. This would prevent a middle-man from intercepting the token and then impersonating the user.

Edit: Also, maybe you need to clarify "My question here, with each request sent from angular, the token are exposed on headers and anyone can have access to them" - I'm curious how anyone could have access to these headers? Also your JWT should be signed and have an expire time set thats respected by the app server.

Answer 2

Security has many layers but there is some stuff that you definitely need to include while securing your API here are some of the more important security measures based on my experience:

1. Access control or Role-based control, this is crucial if you want to secure your API, you need to include some sort of 'Policies' that helps you to manage access to resources within your API in order to secure your data (These too are good options if you ask me Pundit , CanCan , both are good although I prefer Pundit ), this is one way to avoid that a user/cracker using another user access key/token gain access to a resource that is not part of his 'domain'.
2. You need to add the proper security headers to each backend response, this configuration depends on your API and your app, with that said you can add the code below in your application controller for example (the below is a good example of default configuration):

before_action :set_headers

  def set_headers
    response.set_header('Referrer-Policy', 'strict-origin-when-cross-origin')
    response.set_header('X-Content-Type-Options', 'nosniff')
    response.set_header('X-Frame-Options', 'SAMEORIGIN')
    response.set_header('X-XSS-Protection', '1; mode=block')
    response.set_header('Content-Security-Policy', "default-src 'self' https:; " \
        "img-src 'self' https:" \
        "media-src 'none'; " \
        "object-src 'none'; " \
        "script-src 'self'; " \
        "style-src 'self' ")
  end

3. Since you are in rails 5.x you can go to the configuration of your env lets say production.rb and add the following line: config.force_ssl = true , this will force all connections against your API through HTTPS and it will also add this response header strict-transport-security which increment security, be aware that if you try to reach your API via HTTP your API will try to force HTTPS and in some scenarios return a code of 301 which means redirected this is a good hint in case you have a health check.

4. Definitely you need to take care of common issues like Insecure Direct Object Reference (IDOR), this issue as his name indicates is when you have direct references to private resources, let's say in the URL of your app you have something like ***/shop/23 , where 23 is the autoincrement id of your model I think I don't need to explain why is that wrong, from that moment you can be exposed to enumeration attacks, access to info (which you should avoid with authorizations), destroy objects, etc, in these cases one possible approach is to use indirect references or change that id with a value that is not guessable.

5. Last but not less, you need to include proper passwords policies for your users you can look in other sites, or consult NSA for that kind of info.

In most cases security depends on the nature of your application, you may need some other security (for example if your logic includes external links/URLs you may want to check that those links are valid and safe, etc...), but as I said before I think that the list described above is a good fit for a good set of applications, the rest depends on your logic/flows, hope the above helps to clarify.