I'm not an expert of security. I heard it's not recommended to enable GZIP compression for HTTPS requests, that would open a security issue (see SO answer: https://stackoverflow.com/a/4063496/17307650 and https://en.wikipedia.org/wiki/BREACH)

I have an API endpoint in HTTPS and the browser sends a big JSON payload in the body of the request. GZIP is able to improve the performance a lot, shrinking the JSON from 1.2MB down to 56KB.

Instead of enabling GZIP on the server, I achieved an acceptable compromise, sending a "normal" XHR/Fetch request through HTTPS, compressing just the request body with gzip (binary content).

I was wondering, though, would that defeat the purpose of avoiding GZIP at all? Is it possible I re-introduced the same vulnerability mentioned above, or I should be fine? My hope was that it could be a problem if the whole request was gzipped as normal.

I searched on the security StackExchange and found this answer: https://security.stackexchange.com/a/222713/58585

are those "secret ingredients" mentioned all prerequisites for the attack to work, or different ways to avoid the vulnerability? Is it suggesting my body-only compression should be safe, or not?

Clarification: the client is sending a gzip compressed JSON (BODY) representing positions of shapes drawn in the browser by the user. The response returned by the server contains the exact same gzip compressed JSON BODY (exactly as the client sent it) to confirm that payload has been saved to the database. The API is authenticated using a cookie containing a JWT token

PS: the JSON payload doesn't contain sensitive data, and GZIP is used only on (the BODY) that single API endpoint call

  • From your description, it seems like BREACH might not apply. Could you clarify who is compressing what? Are you concerned about the use of compression in the client's request to the API, or concerned about the server's use of compression for the response? What kind of data would be included in the response? If “the JSON payload doesn't contain sensitive data”, then why are you concerned about potential attacks against the confidentiality of this channel?
    – amon
    Commented Jun 8, 2022 at 13:11
  • @amon thanks, I edited the question with additional information
    – Zorgatone
    Commented Jun 9, 2022 at 9:58
  • 1
    If the compressed payload/body doesn't contain both attacker-controlled parts and a secret, then the BREACH attack does not apply. In practice, CORS requests would also be a necessary component. As you describe it, the payload/body only contains user data, no attacker-controlled parts and no secrets.
    – amon
    Commented Jun 9, 2022 at 10:10
  • @anon clear enough! thanks again
    – Zorgatone
    Commented Jun 13, 2022 at 8:28

1 Answer 1


BREACH deals with server responses. The idea is that an attacker sends multiple requests changing one byte. In case the sent byte sequence is contained in the uncompressed response, the compression will be better and the response will be shorter. But in your case you compress data on the client side. That's why your scheme is not vulnerable to BREACH.

Update for the updated question

If HTTP compression is enabled, then BREACH attack is possible.

But if you store GZIP on server unchanged, exactly as the client has sent it, then additional compression on HTTP layer will not give much benefit, in some cases it may make response even slightly bigger than in case without HTTP compression. Thus, you can disable HTTP compression and there should be no big difference in performance.

More important: It seems to be an XY problem. You download file "to confirm that payload has been saved to the database". But such confirmation works only if you compare files in the request and the response, byte by byte. If you don't compare files, it makes no sense to send the whole file back to the client.

Actually, such check is not needed at all. If the server processed data successfully (validated, saved to database, etc.), it should return HTTP 200, otherwise some HTTP 4xx or 5xx code. There is no need to send the file back.

Thus, you can disable HTTP compression on the server and can expect that there will not by any noticeable difference in performance.

  • thanks, I edited the question with further information. The server responds with the same payload the client sent (if it has been saved correctly to the database). The API is authenticated using a cookie containing a JWT token
    – Zorgatone
    Commented Jun 9, 2022 at 9:59
  • I wasn't thinking of enabling server HTTP compression. Just plain HTTPS, the body is gzipped by the application.
    – Zorgatone
    Commented Jun 13, 2022 at 8:30

You must log in to answer this question.

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