-3

How can we safeguard REST API to be accessed only from trusted clients? Let me explain the scenario, lets say there is an API which will be accessed from mobile application MA and web application WA. Besides these two applications, this API should not (and must not) be accessed by any other client.

Key Points:

  • I cannot use token based authentication here, as user is not required to login to application to access (or just read) the information.
  • Embedding any secret information inside the application, to be sent along with the API request, is not secure, as that secret can be leaked (though using SSL) to potential user using reverse engineering.

In this scenario, what is the best way to secure REST API?

Improve this question
1
  • Software engineering has too little to do with magic. You will have to review your expectations regarding security and accessibility.
    – Laiv
    Commented Feb 6, 2018 at 8:11

3 Answers 3

Reset to default
2

You can't. This is why you need to have authentication to assume that they're legitimate and that they're authorized to use them.

Improve this answer
1
  • But that won't prevent anybody to hit the API. Once goes public, it's accessible worldwide.
    – Laiv
    Commented Feb 6, 2018 at 8:09
1

Your going to need some sort of authentication for this. I'd even go as far as to recommend implementing some sort of login system.

The reason for this is simple, there's no way that your API is going to know your clients are trustworthy. It needs some sort of information in order to verify that which ever client is connected is who they say they are. If you can't embed information (you shouldn't anyway), your going to need a login.

Improve this answer
-1

I can't see why you can't implement a token based exchange. You can have an initialization token that starts the communication with the API. This token can be stored in database or however you wish to, and if possible have it change from time to time. Only your client and your server knows of this token, and when it changes.

There's no need for users to be involved in terms of logging in. The token verification can all be done backend without involving user interaction. Everytime your mobile(client) accesses the API with its agreed token, the backend can reshuffle the token, and let the client know what's the new one.

But of course, the security of this is only as strong as the initialization stage. If somehow, there is a way someone could know about the initialization token, they would know the tokens that will be reshuffled from there onwards.

But you get the idea. It is possible. All up to how sneaky you are to design it. There is of course other ways with similar concept.

Improve this answer
7
  • 1
    This is just a different spin on the same thing. The asker explicitly stated that they do not want to embed a (semi-)persistent token in the program or its resources, and if you'd need to store an initialisation token then we're back where we started.
    – Mael
    Commented Feb 6, 2018 at 6:29
  • Yes. His concern on storing the secret on application is on having the secret leaked from the application itself. That's why I am suggesting a constant reshuffle of the tokens once they are used. Every requests will be of different token. Unless that particular person access the API through the client, or have initial connection, else there is no way to reverse engineer to establish a connection as the token is always changing.
    – Desmond
    Commented Feb 6, 2018 at 6:36
  • 3
    And what if I stole the initialisation token? I could then impersonate a legitimate client, because the API server would see that I handed it a valid handshake, and would begin sending me the rest of the tokens. This solution does not solve the original problem, IMO.
    – Mael
    Commented Feb 6, 2018 at 6:47
  • Hence I said that the security of this is only as strong as the initialization stage. But that is a more specific issue to solve than to now think about protecting the entire API. There are ways to do this, for instance the initialization token SHOULD NOT be a static one. Perhaps something you as a developer knows how to come out with. For example my token can be something like this: (single digit minute now)+year+this hour+(double-digit minute now) etc etc of whatever your client side can do. Verify this pattern at the backend for initialization. Like I said, depends on how sneaky you are.
    – Desmond
    Commented Feb 6, 2018 at 7:00
  • 3
    "depends on how sneaky you are" sounds a bit like "security by obscurity" to me
    – Paul Kertscher
    Commented Feb 6, 2018 at 7:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.