The new Certification Class of Learn Spring Security is out:


1. Overview

Spring Security provides several mechanisms to configure a request pattern as unsecured or allowing all access. Depending on each of these mechanisms – this can either mean not running the security filter chain on that path at all, or running the filter chain and allowing access.

Further reading:

Spring Security – Roles and Privileges

How to map Roles and Privileges for a Spring Security application: the setup, the authentication and the registration process.

Read more

Spring Security for a REST API

How to Secure a REST API with Spring Security - the XML Configuration, the web.xml, the HTTP status codes for authentication, etc.

Read more

2. access=”permitAll”

Setting up an <intercept-url> element with access=”permitAll” will configure the authorization so that all requests are allowed on that particular path:

<intercept-url pattern="/login*" access="permitAll" />

Or, via Java configuration:


This is achieved without disabling the security filters – these still run, so any Spring Security related functionality will still be available.

3. filters=”none”

This is a pre-Spring 3.1 feature that has been deprecated and replaced in Spring 3.1.

The filters attribute disables the Spring Security filters chain entirely on that particular request path:

<intercept-url pattern="/login*" filters="none" />

This may cause problems when the processing of the request will require some functionality of Spring Security.

Since this is a deprecated feature Spring versions newer than 3.0, using it with Spring 3.1 will result in a runtime exception on startup:

SEVERE: Context initialization failed
Configuration problem: The use of "filters='none'" is no longer supported. 
Please define a separate <http> element for the pattern you want to exclude 
and use the attribute "security='none'".
Offending resource: class path resource [webSecurityConfig.xml]
	at o.s.b.f.p.FailFastProblemReporter.error(

4. security=”none”

As we saw in the error message above, Spring 3.1 replaces filters=”none” with a new expression – security=”none”.

The scope has changed as well – this is no longer specified at the <intercept-url> element level. Instead, Spring 3.1 allows multiple <http> elements to be defined – each with its own security filter chain configuration. And so, the new security attribute now belongs on at the <http> element level.

In practice, this will look like:

<http pattern="/resources/**" security="none"/>

Or with Java configuration:


Instead of the old:

<intercept-url pattern="/resources/**" filters="none"/>

Similar to filters=”none”, this will also completely disable the Security filter chain for that request path – so when the request is handled in the application, Spring Security features will not be available.

This is not a problem for the examples above, which mainly deal with serving static resources – where no actual processing takes place. However, if the request is handled programmatically in some way – then security functionalities such as requires-channel, accessing the current user or calling secured methods will not be available.

For the same reason, there is no point specifying additional attributes on an <http> element that has already been configured with security=”none” because that request path is unsecured and the attributes will simply be ignored.

Alternatively, access=’IS_AUTHENTICATED_ANONYMOUSLY’ can be used to allow anonymous access.

5. Caveats for security=”none”

When using multiple <http> elements, some configured with security=”none”, keep in mind that the order in which these elements are defined is important. We want to have the specific <http> paths first, followed the universal pattern at the very end.

Also note that, if an <http> element doesn’t specify a pattern, then by default, that maps to the universal match pattern – “/**” – so again, this element needs to be last. If the order of the elements is not correct, the creation of the security filter chain will fail:

Caused by: java.lang.IllegalArgumentException: A universal match pattern ('/**') 
is defined  before other patterns in the filter chain, causing them to be ignored. 
Please check the ordering in your <security:http> namespace or FilterChainProxy bean configuration
	at o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder(
	at o.s.s.c.h.DefaultFilterChainValidator.validate(

6. Conclusion

This article discusses the options of allowing access to a path with Spring Security – focusing on the differences between filters=”none”, security=”none” and access=”permitAll”.

Go deeper into Spring Security with the course:


Sort by:   newest | oldest | most voted

How about using mvc:resource to set this as static link

Eugen Paraschiv

Hey Von – I covered static resources a few days ago actually – here. Cheers,

Kees de Kooter

What would be the Java Config equivalent of this configuration?

Eugen Paraschiv

Hey Kees – thanks for the suggestion – Java config added, hope it helps. Cheers,

Kees de Kooter

Great. Thanks!


It would be nice if you could provide some xml config details.

Eugen Paraschiv

Hey Mitu – what kind of XML configs (besides the ones that are already there)?


Please put the entire XML config file to download for easier understanding, and also mention the library version as the settings of different versions are quite different.

Eugen Paraschiv

The github project contains the full XML configuration (as well as a working project you can use to see it in action) – feel free to grab it from there.
When you’re saying that the configuration is different for different versions – what is the difference you’re thinking of? Cheers,


i’m very exiting with spring security and this blog.
but i got big big problem..
Can spring security security change antMatchers on the fly?

Eugen Paraschiv

Hey Jimmy – I’m glad you’re enjoying the site.
No, unfortunately not, at least not out of the box.
I’m sure, if you really need to – you can do it manually, but it’s going to be a very low level implementation, so I wouldn’t recommend doing it unless you have a really good understanding of the framework.
Hope that helps. Cheers,


Thanks for fast response too Eugen.
The actual problem is that i need to change the user role (their permission to accessing specific urls) on the fly.
Do you have any suggestion?

Eugen Paraschiv
I see; that’s slightly different than, and there are a few ways you could go about it. First – depending on the exact semantics you’re looking for – you can have a look at a custom voter; that’s not exactly going to allow you to change the authorities of a principal after they’re already logged in, but it will give you some control during the authorization process – which may or may not be enough. Second – you can try to log them out; again, that’s not exactly dynamic but – depending on how often it happens, it may be… Read more »

Ok, i will try ACL. Thanks a lot Eugen, Cheers.