Content security policy java

Security HTTP Response Headers

You can use Security HTTP Response Headers to increase the security of web applications. This section is dedicated to WebFlux-based support for Security HTTP Response Headers.

Default Security Headers

Spring Security provides a default set of Security HTTP Response Headers to provide secure defaults. While each of these headers are considered best practice, it should be noted that not all clients use the headers, so additional testing is encouraged.

You can customize specific headers. For example, assume that you want the defaults but you wish to specify SAMEORIGIN for X-Frame-Options .

You can do so with the following configuration:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .frameOptions(frameOptions -> frameOptions .mode(Mode.SAMEORIGIN) ) ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < frameOptions < mode = Mode.SAMEORIGIN >> > >

If you do not want the defaults to be added and want explicit control over what should be used, you can disable the defaults:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers.disable()); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < disable() >> >

Cache Control

Spring Security includes Cache Control headers by default.

However, if you actually want to cache specific responses, your application can selectively add them to the ServerHttpResponse to override the header set by Spring Security. This is useful to ensure that such things as CSS, JavaScript, and images are properly cached.

When using Spring WebFlux, you typically do so within your configuration. You can find details on how to do so in the Static Resources portion of the Spring Reference documentation.

If necessary, you can also disable Spring Security’s cache control HTTP response headers.

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .cache(cache -> cache.disable()) ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < cache < disable() >> > >

Content Type Options

By default, Spring Security includes Content-Type headers. However, you can disable it:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .contentTypeOptions(contentTypeOptions -> contentTypeOptions.disable()) ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < contentTypeOptions < disable() >> > >

HTTP Strict Transport Security (HSTS)

By default, Spring Security provides the Strict Transport Security header. However, you can customize the results explicitly. For example, the following example explicitly provides HSTS:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .hsts(hsts -> hsts .includeSubdomains(true) .preload(true) .maxAge(Duration.ofDays(365)) ) ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < hsts < includeSubdomains = true preload = true maxAge = Duration.ofDays(365) >> > >

X-Frame-Options

By default, Spring Security disables rendering within an iframe by using X-Frame-Options .

You can customize frame options to use the same origin:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .frameOptions(frameOptions -> frameOptions .mode(SAMEORIGIN) ) ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < frameOptions < mode = SAMEORIGIN >> > >

X-XSS-Protection

By default, Spring Security instructs browsers to disable the XSS Auditor by using . You can disable the X-XSS-Protection header entirely:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .xssProtection(xssProtection -> xssProtection.disable()) ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < xssProtection < disable() >> > >

You can also change the header value:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .xssProtection(xssProtection -> xssProtection.headerValue(XXssProtectionServerHttpHeadersWriter.HeaderValue.ENABLED_MODE_BLOCK)) ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < xssProtection < headerValue = XXssProtectionServerHttpHeadersWriter.HeaderValue.ENABLED_MODE_BLOCK >> > >

Content Security Policy (CSP)

By default, Spring Security does not add Content Security Policy, because a reasonable default is impossible to know without the context of the application. The web application author must declare the security policies to enforce and/or monitor for the protected resources.

For example, consider the following security policy:

Content-Security-Policy: script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/

Given the preceding policy, you can enable the CSP header:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .contentSecurityPolicy(policy -> policy .policyDirectives("script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/") ) ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < contentSecurityPolicy < policyDirectives = "script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/" >> > >

To enable the CSP report-only header, provide the following configuration:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .contentSecurityPolicy(policy -> policy .policyDirectives("script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/") .reportOnly() ) ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < contentSecurityPolicy < policyDirectives = "script-src 'self' https://trustedscripts.example.com; object-src https://trustedplugins.example.com; report-uri /csp-report-endpoint/" reportOnly = true >> > >

Referrer Policy

By default, Spring Security does not add Referrer Policy headers. You can enable the Referrer Policy header using configuration as shown below:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .referrerPolicy(referrer -> referrer .policy(ReferrerPolicy.SAME_ORIGIN) ) ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < referrerPolicy < policy = ReferrerPolicy.SAME_ORIGIN >> > >

Feature Policy

By default, Spring Security does not add Feature Policy headers. Consider the following Feature-Policy header:

Feature-Policy: geolocation 'self'

You can enable the preceding Feature Policy header:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .featurePolicy("geolocation 'self'") ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < featurePolicy("geolocation 'self'") >> >

Permissions Policy

By default, Spring Security does not add Permissions Policy headers. Consider the following Permissions-Policy header:

Permissions-Policy: geolocation=(self)

You can enable the preceding Permissions Policy header:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < http // . .headers(headers ->headers .permissionsPolicy(permissions -> permissions .policy("geolocation=(self)") ) ); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < return http < // . headers < permissionsPolicy < policy = "geolocation=(self)" >> > >

Clear Site Data

By default, Spring Security does not add Clear-Site-Data headers. Consider the following Clear-Site-Data header:

Clear-Site-Data: "cache", "cookies"

You can send the Clear-Site-Data header on logout:

@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) < ServerLogoutHandler securityContext = new SecurityContextServerLogoutHandler(); ClearSiteDataServerHttpHeadersWriter writer = new ClearSiteDataServerHttpHeadersWriter(CACHE, COOKIES); ServerLogoutHandler clearSiteData = new HeaderWriterServerLogoutHandler(writer); DelegatingServerLogoutHandler logoutHandler = new DelegatingServerLogoutHandler(securityContext, clearSiteData); http // . .logout() .logoutHandler(logoutHandler); return http.build(); >

@Bean fun webFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain < val securityContext: ServerLogoutHandler = SecurityContextServerLogoutHandler() val writer = ClearSiteDataServerHttpHeadersWriter(CACHE, COOKIES) val clearSiteData: ServerLogoutHandler = HeaderWriterServerLogoutHandler(writer) val customLogoutHandler = DelegatingServerLogoutHandler(securityContext, clearSiteData) return http < // . logout < logoutHandler = customLogoutHandler >> >

Apache®, Apache Tomcat®, Apache Kafka®, Apache Cassandra™, and Apache Geode™ are trademarks or registered trademarks of the Apache Software Foundation in the United States and/or other countries. Java™, Java™ SE, Java™ EE, and OpenJDK™ are trademarks of Oracle and/or its affiliates. Kubernetes® is a registered trademark of the Linux Foundation in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Windows® and Microsoft® Azure are registered trademarks of Microsoft Corporation. “AWS” and “Amazon Web Services” are trademarks or registered trademarks of Amazon.com Inc. or its affiliates. All other trademarks and copyrights are property of their respective owners and are only mentioned for informative purposes. Other names may be trademarks of their respective owners.

Источник

CSP Java Example

By referencing the HTTP Servlet API, we can use the addHeader method of the HttpServletResponse object.

response.addHeader("Content-Security-Policy", "default-src 'self'");

Your policy will go inside the second argument of the addHeader method in the example above.

Using your Web Server

Instead of writing the header directly from your Java code or JSP code, you can instead use your web server to write the header. For example CSP with nginx or CSP with Apache via htaccess.

Writing a HTTP Servlet Filter

If you want to apply the same policy to all requests to your java application server you can create a simple HTTP Servlet Filter. It is usually easier to use the web server, if you have one, but if you are serving requests directly from Apache Tomcat, or another J2EE server a Servlet Filter may be a good way to go.

Here is an example java servlet filter to add a CSP response header:

package com.content-security-policy.filters; import javax.servlet.Filter; import javax.servlet.FilterConfig; import javax.servlet.ServletException; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; import javax.servlet.FilterChain; import javax.servlet.http.HttpServletResponse import java.io.IOException; public class CSPFilter implements Filter < public static final String POLICY = "default-src 'self'"; @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException < if (response instanceof HttpServletResponse) < ((HttpServletResponse)response).setHeader("Content-Security-Policy", CSPFilter.POLICY); >> > @Override public void init(FilterConfig filterConfig) throws ServletException < >@Override public void destroy() < >>

Then enable the java servlet filter in your web.xml :

 CSPFilter com.content-security-policy.filters.CSPFilter  CSPFilter /*  

What goes inside a CSP policy?

If you’re not sure what default-src ‘self’; means, then check out the Content Security Policy reference for details. That is just a really simple example of a policy, your policy will probably need to be more complex than that.

CSP Developer Field Guide

Want to learn the ins and outs CSP? Grab a copy of the CSP Developer Field Guide. It’s a short and sweet guide to help developers get up to speed quickly.

Struggling to stay on top of security advisories?

Advisory Week is a weekly roundup of all the security advisories published by the major software vendors.

Источник