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