Skip to content

HTTP hardening#3067

Merged
stgraber merged 5 commits intolxc:mainfrom
stgraber:hardening
Mar 23, 2026
Merged

HTTP hardening#3067
stgraber merged 5 commits intolxc:mainfrom
stgraber:hardening

Conversation

@stgraber
Copy link
Copy Markdown
Member

This applies a number of hardening recommendations identified by the team @7aSecurity (https://7asecurity.com/)

We've apparently always turned off this particular safety check but
can't find a good reason for that as all complex Websocket operations
are done outside of the browser.

For browser-based interactions, the default behavior of enforcing an
Origin match seems quite appropriate.

Reported-by: https://7asecurity.com
Signed-off-by: Stéphane Graber <[email protected]>
The existing logic was likely taken from Minio's examples where TLS 1.2
is always explicitly set as the minimum version.

I couldn't find any reason for why this needs to be done when dealing
with standard public S3 compatible APIs, so let's make it use our normal
base config which will then respect the INCUS_INSECURE_TLS environment
variable should TLS 1.2 really be required.

Reported-by: https://7asecurity.com
Signed-off-by: Stéphane Graber <[email protected]>
Our OIDC cookies are only ever used as part of user driven HTTP(S)
requests and don't need to be accessible directly to Javascript.

The current policy was likely set expecting the Javascript client to
need to check or directly interact with the cookies to handle renewal
and such, similar to what the Go client does.

But this didn't turn out to be needed and OIDC is effectively handled
transparently by the web browser instead.

Reported-by: https://7asecurity.com
Signed-off-by: Stéphane Graber <[email protected]>
This configures some timeouts on the HTTP server to prevent clients from
keeping connections open longer than they should.

We can generally have reasonable timeouts on receiving headers and
receiving the client's request. We however can't easily put timeouts in
place in the other direction as we have to support long-poll style
endpoints in this API.

Reported-by: https://7asecurity.com
Signed-off-by: Stéphane Graber <[email protected]>
This configures some timeouts on the HTTP server to prevent clients from
keeping connections open longer than they should.

Depending on the endpoints, we can either just timeout on the receiving
side (headers, request body) or also on the sending direction (client
reading the response).

Endpoints that need to support long-poll style APIs or need to handle
potentially very large requests (file uploads, connection upgrades, ...)
only get to benefit from the header timeout logic.

Reported-by: https://7asecurity.com
Signed-off-by: Stéphane Graber <[email protected]>
@stgraber stgraber merged commit c1a5aba into lxc:main Mar 23, 2026
158 of 160 checks passed
tomponline added a commit to canonical/lxd that referenced this pull request Mar 25, 2026
From lxc/incus#3067 with some additional
improvements in the same vein.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants