Hackathon 25.3: CSS files pulled in with @import from a stylesheet are blocked by the default security setup

[manolo]

Description

@StyleSheet("styles.css") is served. The files that stylesheet @imports are ordinary browser requests for static resources, and VaadinSecurityConfigurer does not permit them, so each one redirects to the login view, which redirects again, and the browser gives up:

ERR_TOO_MANY_REDIRECTS

The page then renders with the main stylesheet and none of its imports.

Why it matters

Splitting CSS into files and pulling them together with @import from one entry point is ordinary, and it is what the Vaadin documentation suggests for organising styles. In a secured application it silently produces an unstyled page.

The failure names redirects, so the first guess is the security configuration for the view, not the stylesheet.

Expected

Permit static CSS under the resource paths the framework already serves, the way styles.css itself is permitted, or say on the styling page that imported files need a matcher of their own.

Workaround

Permit the directory explicitly:

.requestMatchers("/styles/**").permitAll()

Reproduce

39-imported-css.zip: a secured application with one user in memory, @StyleSheet("styles/main.css") on an anonymous view, and main.css importing parts.css. The security setup permits /styles/main.css and nothing else, which is the state an application reaches after somebody notices the declared sheet redirecting and adds a matcher for it.

mvn spring-boot:run, then ask the server:

curl -o /dev/null -w "%{http_code} -> %{redirect_url}" http://localhost:8139/styles/main.css
200
curl -o /dev/null -w "%{http_code} -> %{redirect_url}" http://localhost:8139/styles/parts.css
302 -> http://localhost:8139/login

Open http://localhost:8139/. main.css applied, its import did not: the body font is sans-serif from main.css, and the heading is the default colour instead of the pink parts.css sets.

The console is the part worth fixing, whatever happens to the rest. It names the file that worked:

Failed to load resource: net::ERR_TOO_MANY_REDIRECTS   http://localhost:8139/login
Error loading http://localhost:8139/styles/main.css
'http://localhost:8139/styles/main.css' could not be loaded.

Comment the matcher out and the declared sheet fails the same way, which is the general form: with the default VaadinSecurityConfigurer no static CSS under META-INF/resources is permitted, entry point included.

Getting the project

39-imported-css.zip, 5 KB, sources only. Unzip it and:

mvn spring-boot:run

Found on 25.3.0-beta1.

[totally-not-ai]

Reproduced on the attached project. Two separate things are happening here, and only one of them is a bug.

1. Static CSS not being permitted is the current design

With VaadinSecurityConfigurer the default anyRequest rule is denyAll(), and the permitted set is a fixed list (HandlerHelper.getPublicResources() / getPublicResourcesRoot()): /styles.css, /themes/**, /assets/**, /lumo/**, /aura/**, /favicon.ico, the PWA manifest/offline/icon paths and /VAADIN/**. Anything else under META-INF/resources needs a rule of its own — for anybody, not just anonymous users. On the repro project, /styles/parts.css is 403 even when logged in.

This exact question was raised in #22476 (@StyleSheet + Spring Security, including the @import 'components.css' case) and closed with the decision that these rules belong in application code, with styles.css kept public so the simple single-file case works. The suggested shape there was:

auth.requestMatchers(PathRequest.toStaticResources().atCommonLocations()).permitAll();

with imported sheets under a common location, e.g. META-INF/resources/css/parts.css. So unless that decision is being revisited, this part is a documentation gap on the styling page rather than a framework bug: the page recommends splitting CSS with @import without mentioning that every file other than the entry point needs to be permitted.

If the team does want to revisit it, the options look like:

• Document it on the styling page (cheapest, matches the Make it easier to include custom stylesheets when using Spring Security #22476 decision).
• A public styles/** folder, the way /themes/** and /assets/** are public today — one predictable place for hand-written CSS, no annotation scanning, no recursive @import parsing.
• Inline the imports when serving the declared sheet, so only the entry point is ever requested. Solves it completely, but it means parsing and rewriting CSS (relative url() references, media queries, layer()) — clearly its own piece of work.

2. ERR_TOO_MANY_REDIRECTS is a real bug

The redirect loop is not about the view's security configuration, and it hides the file that was actually blocked. The chain, verified with curl against the repro:

GET /styles/parts.css  (Sec-Fetch-Dest: style)  -> 302 /login   # denied, redirect to the login view
GET /login             (Sec-Fetch-Dest: style)  -> 302 /login   # loops here

The second hop loops because the redirected request is still a stylesheet request: IndexHtmlRequestHandler.canHandleRequest rejects it via isRequestForHtml (HandlerHelper.isNonHtmlInitiatedRequest), so Flow does not serve the app shell, the container turns the 404 into an ERROR dispatch to /error, that is denied by anyRequest().denyAll() and redirected to /login again — with Sec-Fetch-Dest: style still attached. Hence the browser giving up on /login, and the console naming main.css (the sheet whose <link> failed) instead of parts.css.

Redirecting a stylesheet, script, image or font request to a login view is never useful — those requests cannot render one. Root cause: VaadinSecurityConfigurer installs a single LoginUrlAuthenticationEntryPoint for AnyRequestMatcher, so sub-resource requests get the same redirect as a page request.

Proposed fix (draft PR opened): register an HttpStatusEntryPoint(401) for requests that HandlerHelper.isNonHtmlInitiatedRequest recognizes as non-HTML initiated, ahead of the login-URL entry point, keeping the redirect for HTML requests. This is the same pattern already used for Hilla endpoint requests, and the same Sec-Fetch-Dest check VaadinDefaultRequestCache already uses to decide not to save such requests. The blocked request then answers 401 immediately, no loop, and the console points at /styles/parts.css — the file that actually needs a matcher.

Note this fixes the misleading failure, not the styling behaviour: the imported sheet is still not served until item 1 is decided. Left for a maintainer decision, since both touch policy rather than a defect:

• whether to extend the same 401 handling to the OAuth2 login page (same loop, but the entry-point ordering interacts with OAuth2LoginConfigurer, so it was left alone here);
• whether VaadinSecurityConfigurer should permit the Spring Boot ERROR dispatch — today any 404 in a secured application becomes a login redirect (anonymous) or a 403 (authenticated), which is what turns the second hop into a loop in the first place.