0

I have searched all over the internet for the last days and not found a single example without it saying it's not safe and the same thing everywhere.

But also couldn't find cases like my use case so I had to ask it for myself.

The scenario: I have a backend which on only some of the data it sends I need some sort of extra security so other people won't be using my api publicly, I have successfully used Laravel's Crypto for encryption on backend and CryptoJs for decryption on the frontend.

So my only problem is where to store my larave's key which is used for AES encryption and decryption on frontend.

What I have already tried (or thought of):

  • .env files, they get included in the bundle anyways so what's the point.
  • Any obfuscation sound to be pointless.

I probably should use WebCrypto (https://stackoverflow.com/a/24677597/10268067) but couldn't get anywhere with it. (I just heard of it).

I need some suggestions, even if there was a secure way of storing my encryption key, I don't think there is a way to do it directly so I have to request my api for this encryption key at some point but where? If I have a route specifically for this purpose I don't think the hackers are too stupid to find that, heck I can even find that with interception of the requests and responses!

So I basically have two problems:

  1. How to request the server somehow randomly or in anyways that hackers can hardly ever find my encryption key in the requests.
  2. How to save in on js side of browser securely, for instance I decided to use Secure Store for my mobile app's version of this exact problem, but on the web I'm so lost!

Just to be clear, encryption happens on the backend, decryption (with the same key) happens on the frontend.

Steve Moretz
  • 2,758
  • 1
  • 17
  • 31
  • 1
    The main question is if you want client side or server side encryption, does not matter if it is JavaScript - it only confuses people if you start talking about JavaScript because some assume that it directly means client / frontend while others assume node in the backend. And in both client and server side encryption you need to clearly state why you want it, who to protect what data from and how. Each client has their own key or does the server only have one key? If client side encryption: what if I log in from a different device? You probably need a PBKDF in that case. – luk2302 Sep 11 '22 at 21:08
  • 1
    For frontend API keys service provider should allow you to narrow allowed domains to use that API key, so you will be safe. You don't need to deal with additional encryption. – Daniel Sep 11 '22 at 21:10
  • @luk2302 Sorry I thought it was cleared I updated and added a little part which answers to your questions, it's not client-side encryption. – Steve Moretz Sep 12 '22 at 06:35
  • @Daniel Don't exactly get what you mean, are you talking about cors? cause the api is supposed to work from a mobile application too, so cors won't help it's not just a website client also a mobile client which means those request don't come from the same domain (Cause it's not possible it's just a mobile application which is not on the same domain) – Steve Moretz Sep 12 '22 at 06:38
  • Then encryption is simply the wrong tool and in fact there is no tool to achieve what you want. You have an unauthenticated API and want to protect it from unauthorized applications. How do to that? By adding authentication. Encryption does not help here at all. – luk2302 Sep 12 '22 at 07:21
  • @luk2302 Thanks for the reply, yeah that's why I asked it I reached a dead-end, so I thought maybe there are ways to achieve it or at least make it harder for hackers which I couldn't think of, but sounds like there is no way :), so your way is authentication + like a rate limiter like what google does for instance right? – Steve Moretz Sep 12 '22 at 07:54
  • @SteveMoretz I mean that i.e. when you use Google Maps API, you decide which domains are allowed to use that API key. There is no need to encrypt it, you just put it into your frontend. Calls from other unallowed domains are rejected and your usage quota isn't affected. – Daniel Sep 13 '22 at 07:47
  • @Daniel how does google maps api restrict that for mobile app though? As I mentioned I also have mobile applications so the domain wouldn't do it unfortunately :( – Steve Moretz Sep 13 '22 at 14:35
  • @SteveMoretz for mobile applications, you have to use Google Maps SDK for Android (or iOS). – Daniel Sep 14 '22 at 13:23

1 Answers1

0

I have a backend which on only some of the data it sends I need some sort of extra security so other people won't be using my api publicly

Cryptography is not the solution for this. Big companies use API tokens and refresh tokens in order to accomplish this.

The solution you are looking for is called refresh tokens used along with the API tokens.

kjoedion
  • 562
  • 1
  • 8
  • It's another way to look at it, sounds interesting yet what you are referring to needs authentication but my concept is in a general non-authenticated way, I do have authentication features on my backend (with jwt tokens and such) and I can restrict them yet I'm talking about restricting a public api which people can access without providing any information or ways of authentication. – Steve Moretz Sep 12 '22 at 06:41