I have a spring REST controller which returns the following JSON payload:
[
{
"id": 5920,
"title": "a title"
},
{
"id": 5926,
"title": "another title",
}
]
The REST controller with its corresponding get request method:
@RequestMapping(value = "example")
public Iterable<Souvenir> souvenirs(@PathVariable("user") String user) {
return new souvenirRepository.findByUserUsernameOrderById(user);
}
Now the Souvenir class is a pojo:
@Entity
@Data
public class Souvenir {
@Id
@GeneratedValue
private long id;
private String title;
private Date date;
}
Regarding https://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines#Always_return_JSON_with_an_Object_on_the_outside and http://haacked.com/archive/2009/06/25/json-hijacking.aspx/ I would like to wrap the response within an object so that it is not vulnerable to attacks. Of course I could do something like this:
@RequestMapping(value = "example")
public SouvenirWrapper souvenirs(@PathVariable("user") String user) {
return new SouvenirWrapper(souvenirRepository.findByUserUsernameOrderById(user));
}
@Data
class SouvenirWrapper {
private final List<Souvenir> souvenirs;
public SouvenirWrapper(List<Souvenir> souvenirs) {
this.souvenirs = souvenirs;
}
}
This results in the following JSON payload:
{
"souvenirs": [
{
"id": 5920,
"title": "a title"
},
{
"id": 5926,
"title": "another title",
}
]
}
This helps in preventing some JSON/Javascript attacks but I don't like the verbosity of the Wrapper class. I could of course generalize the above approach with generics. Is there another way to achieve the same result in the Spring ecosystem (with an annotation or something similar)? An idea would be that the behaviour is done by Spring automatically, so whenever there is a REST controller that returns a list of objects, it could wrap those objects within an object wrapper so that no direct list of objects get serialized?
I ended up with the following solution (thanks to @vadim-kirilchuk):
My controller still looks exactly as before:
I added the following implementation of
ResponseBodyAdvice
which basically gets executed when a controller in the referenced package tries to respond to a client call (to my understanding):So with this approach I can keep my existing method signature in my controller (
public Iterable<Souvenir> souvenirs(@PathVariable("user") String user)
) and future controllers don't have to worry about wrapping its Iterables within such a wrapper because the framework does this part of the work.