Troubles with CSP headers on by default

Hi all,
I’m writing to the dev list as I’m facing extended troubles with the CSP headers being on by default, and I’m not getting any traction trying to discuss the issues on the PR that triggered them.

Long story short, there is a number of problems in the GeoServer GUI, several parts of which are not working any longer to due CSP blocking some of the page functionality.

Many of the problems seem to originate in some sort of HTTP caching of the pages, where the CSP headers are enabled anyways (OPTIONS/preflight requests maybe?) but the content of the page is outdated. Not sure why it’s happening, but I see it a lot: I can regain full functionality of some pages by force reloading them (CTRL-F5), while others just do not work.

One example is the layer preview page, the format dropdowns would not work and open a preview with the selected format (with a CSP error) until I force reload the page.

One more thing I’ve noticed is that the issues are not the same when running locally, or running in a published web site, with more issues when running in a published website (typically fronted by nginx or apache), even if the caching headers are still set to “not cache” (max-age=0 and the like).

First of all, can anyone else reproduce these issues?

If so, we shoudl think of something… even if CSP is not entirely at fault here, plenty of people upgrading will just assume the GUI broke, and even for those that do read the upgrade instructions, we cannot really ask them to force reload every page.

Cheers
Andrea

I have not had an opportunity to work with the CSP headers on by default.

Eh, why does a moderator need to approve my post?

Yes, I am having the same problems on 2.27.x (main) deployed for CITE testing.

Refused to send form data to ‘https://___________/geoserver/j_spring_security_check’ because it violates the following Content Security Policy directive: “form-action ‘self’”.

Refused to load the stylesheet ‘https://___________/geoserver/web/wicket/resource/org.wicketstuff.select2.ApplicationSettings/res/css/select2-ver-E6DE4A7C42DF8ED98269C8B60F7C4DCD.css’ because it violates the following Content Security Policy directive: “style-src ‘nonce-lUa1lE_1TRo674n0kKTLQEFi’”. Note that ‘style-src-elem’ was not explicitly set, so ‘style-src’ is used as a fallback.

I concur with reverting the PR [GEOS-11346] Enable strict Content-Security-Policy by default by sikeoka · Pull Request #8167 · geoserver/geoserver · GitHub while resolving this.

Peter

I don’t know if it’s a proxy configuration issue, a GeoServer configuration issue or a bug in the GeoServer code but the form-action 'self' CSP violations are actually because the server is redirecting the HTTPS request to HTTP so they are considered to be different origins (https://gs-main.geosolutionsgroup.com to http://gs-main.geosolutionsgroup.com). The HTTP URL returns a 404 Not Found error so this redirection can cause requests to fail even when it isn’t blocked by CSP.

HTTP/1.1 302
Server: nginx
Date: Tue, 28 Jan 2025 16:01:36 GMT
Content-Length: 0
Connection: keep-alive
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: base-uri 'self'; form-action 'self'; default-src 'none'; child-src 'self'; connect-src 'self'; font-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self';, frame-ancestors 'self';
Set-Cookie: remember-me=; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/geoserver
Location: http://gs-main.geosolutionsgroup.com/geoserver/web/wicket/bookmarkable/org.geoserver.web.GeoServerLoginPage?error=true
Access-Control-Allow-Origin: https://gs-main.geosolutionsgroup.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE
Access-Control-Allow-Headers: DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range
Access-Control-Expose-Headers: Content-Length,Content-Range
1 Like

Yep, that’s for the login button, however when I fail to switch tabs I have a HTTPS reference:

Hum… MapML eh? Maybe a CSP issue specific to that module.
I can’t remove it from the server though.

Also when not being able to save the authentication settings, it’s HTTPS as well:

Trying to save the “passwords” page has a similar outcome, maybe a common origin:

I’m seeing the same in other “save” buttons from pages under the “Security” menu, but also in service configuration pages.

Eh, why does a moderator need to approve my post?

We had some trouble with spam on discourse last week and folks have been adjusting settings to try and cope.

1 Like

Hi,

I think I’m finding CSP issues - I saw some CSP errors in the browser. I turned them off with org.geoserver.web.csp.strict=false and now there’s no errors in my js console.

However, when I access the WCS request builder, and click on an EPSG code (to pop up a dialog), nothing happens. Looking into it…

Dave

On Wed, Jan 29, 2025 at 11:47 AM Jody Garnett via OSGeo Discourse <noreply@discourse.osgeo.org> wrote:

jive Leader
January 29

Eh, why does a moderator need to approve my post?

We had some trouble with spam on discourse last week and folks have been adjusting settings to try and cope.


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

Just two more notes:

Tomcat: The scheme (=protocol) Tomcat shall assume on inbound requests is directly configurable, regardless of the real protocol in use. See scheme in Apache Tomcat 9 Configuration Reference (9.0.98) - The HTTP Connector
Of course this breaks accessing Tomcat directly using HTTP.

Apache HTTPD: It has the ProxyPassReverse directive for rewriting redirects etc, see mod_proxy - Apache HTTP Server Version 2.4