I just announced the newSpring Security 5 modules (primarily focused on OAuth2) in the course:

>> CHECK OUT LEARN SPRING SECURITY

1. Overview

In this article, we’ll learn how to use the @PreFilter and @PostFilter annotations to secure operations in a Spring application.

When used together with the authenticated principal information, @PreFilter and @PostFilter allows us to define fine-grained security rules using Spring Expression Language.

2. Introducing @PreFilter and @PostFilter

Simply put, the @PreFilter and @PostFilter annotations are used to filter lists of objects based on custom security rules we define.

@PostFilter defines a rule for filtering the return list of a method, by applying that rule to every element in the list. If the evaluated value is true, the item will be kept in the list. Otherwise, the item will be removed.

@PreFilter works in a very similar fashion, however, the filtering is applied to a list that is being passed as an input parameter to the annotated method.

Both annotations can be used on methods or types (classes and interfaces). We’ll use them only on methods throughout this article.

Theses annotations are not active by default – we’ll need to enable them with the @EnableGlobalMethodSecurity annotation and prePostEnabled = true – in our security configuration:

@Configuration
@EnableWebSecurity
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
    // ...
}

3. Writing Security Rules

To write the security rules in these two annotations – we’ll make use of Spring-EL expressions; we can also use the built-in object filterObject to get a reference to the particular list element being tested.

Spring Security provides many other built-in objects to create very specific and exact rules.

For example, we can use @PreFilter to check if the assignee property of a Task object is equal to the name of the currently authenticated user:

@PostFilter("filterObject.assignee == authentication.name")
List<Task> findAll() {
    ...
}

We’ve used the @PostFilter annotation here since we want the method to execute and get all tasks first, and they pass every single task from the list through our filter rule.

So, if the authenticated user is michael, the final list of tasks returned by the findAll method would only contain the tasks that are assigned to michael, even if the database has tasks assigned to jim and pam.

Now let’s make the rule a little bit more interesting. Assume that if a user is a manager they can see all tasks, regardless of whom they are assigned to:

@PostFilter("hasRole('MANAGER') or filterObject.assignee == authentication.name")
List<Task> findAll() {
    // ...
}

We’ve used the built-in method hasRole to check if the authenticated user has the role of MANAGER. If hasRole returns true, the task will be kept in the final list. So, if the user is a manager, the rule will return true for every item in the list. Thus the final list will contain all items.

Now let’s filter a list passed as a parameter to a save method using @PreFilter:

@PreFilter("hasRole('MANAGER') or filterObject.assignee == authentication.name")
Iterable<Task> save(Iterable<Task> entities) {
    // ...
}

The security rule is the same as the one we’ve used on the @PostFilter example. The main difference here is that the list items will be filtered before the method executes, thus allowing us to remove some items from the list, preventing them from being saved in the database.

So jim, who is not a manager, may try to save a list of tasks, some of which are assigned to pam. However only those tasks assigned to jim will be included, the other ones will be ignored.

4. Performance on Large Lists

@PreFilter is really cool and easy to use, but it can be inefficient when dealing with very large lists since the fetching operation will retrieve all the data and apply the filter afterward.

Imagine, for example, that we have thousands of tasks in our database and we want to retrieve the five tasks that are currently assigned to pam. If we use @PreFilter, the database operation will fetch all the tasks first, and iterate through all of them to filter out the ones that are not assigned to pam.

5. Conclusion

This quick article explained how to create a simple, but secure, application using Spring Security’s @PreFilter and @PostFilter annotations.

Check the complete code example in this Github repository.

I just announced the new Spring Security 5 modules (primarily focused on OAuth2) in the course:

>> CHECK OUT LEARN SPRING SECURITY

newest oldest most voted
Notify of
Mike Borman
Guest
Mike Borman

Are the descriptions for @PreFilter and @PostFilter transposed in paragraph #2?

Grzegorz Piwowarek
Guest
Grzegorz Piwowarek

What do you mean by “transposed”?

Ken Krueger
Guest
Ken Krueger

Same question. They look backwards to me. I think it is supposed to say “@PostFilter defines a rule for filtering the return list of a method…” and “@PostFilter … is applied to a list that is being passed as an input parameter…”

Felipe Reis
Guest
Felipe Reis

Hey Mike! Thanks for letting us know 😉 It should all good now.

Eralp Bayraktar
Guest
Eralp Bayraktar

Do you have a real-world example where these filters are useful? Because whatever you do I can clearly see they will be inefficient too soon, or it’s a security risk for multi-tenant usecases.

Felipe Reis
Guest
Felipe Reis

These are simple solutions to solve simple permissions scenarios. It is definitely not a good option for large lists. You would probably try to implement a more performant query if you’re working with lists coming from a big database table, for instance. Another scenario when these annotations can come in useful is when you don’t have complete control over the underlying code that actually fetches the list or that prepares the list that is then passed as a method parameter. Like when working with a third party library or API. In those cases, you can either implement some logic inside… Read more »

Eralp Bayraktar
Guest
Eralp Bayraktar

That makes a lot of sense, the example with the 3rd party libraries. You can’t reduce the performance hit anyway if you have to filter, and this is a more standart way that also helps the code-maintainer.

Felipe Reis
Guest
Felipe Reis

Glad I could help 😉

sauro
Guest
sauro

how to tell user that ..these objects can not be supported …and send an Exception

Grzegorz Piwowarek
Guest
Grzegorz Piwowarek

What do you mean by “objects”?

sauro
Guest
sauro

elements of list.

Grzegorz Piwowarek
Guest
Grzegorz Piwowarek

Ok, those can be used only for simple filtering and for the use case you mentioned.

Here, we are dealing with security and users without necessary permissions should not be able to be informed about resources they can’t access.

sauro
Guest
sauro

thats not my answer .. i want to know , just like @preAuthorized throws Exception so we can send it to client side..what in @filter we can send a failure msg to client about filter out elements of list…its my project requirment.