I have a client which requires some currently public API endpoints be encrypted and secure (although it's more of a checkbox than anything I worry about someone attacking, or I would not accept the task). I am using https, get and post requests from a JavaScript based phone application to a Rails backend. There is a simple login performed before data is downloaded where an API key could be sent back along with the successful login.

I am wondering if the only step needed here is to add an API key to those get and post API requests (ie a password stored clientside) or if there is some real benefit to digging into OpenSSL encrypting and decrypting, doing a handshake with RSA to get an AES key etc... Am I correct in guessing that https is already doing this in a tried and true method and that hacking it on my own would be at best wasting my time, at worst introducing new vulnerabilities?

Would there be a point in encrypting a password before an https post request, or is it already being encrypted by the jquery post request? Is there a point in encrypting the api endpoints and manually decrypting them clientside with something like webcrypto, or is this already happening behind the scenes in https?

1 Answer 1


Am I correct in guessing....


Would there be a point in encrypting a password before an https post request,

No point. It's already encrypted. But you do need to think about what you are going to compare it with serverside to validate it - the stored password should encrypted using a suitable password hash/

You must log in to answer this question.

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