2

I am developing a web application which will require users to provide 3rd party API keys through the client, which will then be used to make requests to the 3rd party API from the backend of my app.

After researching, I believe the best way, and standard practice, is to store these API keys as plain text in my database.

However, my question lies in the security of these keys while they are in the process of being sent from the client to the database.

To further clarify, the 3rd party API keys will be entered by users client-side through a standard HTML form, and upon being submitted, the client will make a post request to my backend, which will in turn store the keys in mongodb.

Would bad actors be able to access these keys via dev tools or some other malicious means while they are in the process of being sent from the client to the backend?

If so, what actions can I take in order to secure them further while they are being sent from client to db?

Improve this question

3 Answers 3

Reset to default
1

Yeah because this requires clear-text recovery it is less in your hands.

  • only do this strictly using https
  • enforce extra field "request domain" so only yourapp.com can use it if stolen
  • only using POST never GET (avoid logs / history)
  • use input type=password so it appears as *******
  • prevent user from also recover it / instead force them get new one (stops leaky staff member)
  • suggest the user set short expiry timeout

Not sure if I would bother setting up symmetric encryption as I said it's kinda not your problem but make it easy to revoke the key :) Maybe store it in the browser encrypted store but that won't work server to server.

Improve this answer
1
  • FWIW a few years later, as the original post is tagged with MongoDB, it's also worthwhile recommending Client-Side Field Level Encryption. Though by "client" the MongoDB docs don't mean something like a web browser making POST requests, they mean the bit that connects from the OP's "backend" to the MongoDB deployment. Depending on the threat model (which we don't have), API keys could well be more valuable than passwords so may deserve an equal or better level of protection.
    – pzrq
    Commented Jul 18, 2023 at 7:31
0

An API key is basically a password. The usual protections like transport with TLS (i.e. use HTTPS) should therefore be sufficient.

Improve this answer
0

Most APIs today use an API Key to authenticate legitimate clients to web services. API Keys are very simple to use from the client's perspective:

  • You get an API key from the service (in essence a shared secret).
  • Add the key to an Authorization header.
  • Call the API.

There are several ways to protect your API Key such as:

  1. Encryption: Since you have control in your Backend, you can implement an encryption/decryption method from front-end to the backend. You can put a middleware that decrypts the payload.

    client -> encryped-body -> api -> controller (middleware decrypt body) -> db

  2. Use HTTPS: The traffic will be encrypted, MITM attack won't work.

  3. Use POST and not GET request

  4. Use JWT for additional security for your REST API: https://blog.logrocket.com/secure-rest-api-jwt-authentication/

I'd like to answer your question

Would bad actors be able to access these keys via dev tools or some other malicious means while they are in the process of being sent from the client to the backend?

Answer:

Dev Tools are for Development and Debugging, Malicious hackers can't see anything, they can see what they supplied on the web form using burpsuite(basically they don't know your key). This will be sniffed if your site is not using HTTPS/HTTP.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .