Payload before encryption :

HTTP/1.1 200 OK
Authorization: password
Content-Encoding: UTF-8
Content-Length: 138

{ "command" : "delete all records" }

Payload after encrypting Authorization header :

HTTP/1.1 200 OK
Authorization: spxnxkoJX+O1iatF6gco9Q==
Content-Encoding: UTF-8
Content-Length: 138

{ "command" : "delete all records" }

Protocol is NOT over SSL.


In our project, my senior added this extra layer of security(as per his opinion), with which I am not agree. As per my opinion, this will add an extra cost of encryption and decryption of header value and without any security benefit.

I want to ensure, if he is really right?

  • 1
    While I agree with everything Steffen says, I'm now wondering whether his answer addresses the question. I'm struggling to imagine why the HTTP response should require authorization. I've only ever seen it in HTTP requests. Further, where the server did need to prove itself to the client (in a world without SSL) why is the being sent as a header and not in the body of the response.
    – symcbean
    Commented Jul 13, 2016 at 10:14
  • Advise using SSL instead of encrypting the authorization header. See this thread Commented Jul 13, 2016 at 18:41

1 Answer 1


Does encrypting HTTP header value provide additional security?

There is no general response for this but it depends on what exactly you are doing and what kind of "additional security" you aim for.

In your case it looks that you just replaced a plain text password with an encrypted password. Unless you have some replay protection baked into your unknown encryption algorithm the attacker could just sniff your encrypted password and replay it later. Which means it does not really provide additional security if your goal is to make authentication more secure. If your goal is instead to only hide the plain text password to make password reuse attacks harder then encryption might help.

You must log in to answer this question.

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