Spring Security sets default security headers to help protect the application. The default security headers injected by Spring Security are:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

These are reasonable headers that help protect the application. Do not disable these headers unless they are replaced by more restrictive values.

Example 1: The following code disables Spring Security default headers:

	<http auto-config="true">
        ...
        <headers disabled="true"/>
        ...
	</http>

Spring Security includes an HTTP firewall that helps protect the application by sanitizing requests that contain potentially malicious characters. Spring achieves this by including the HttpFirewall into its FilterChainProxy, which processes the requests before they are sent through the filter chain. Sprint Security uses the StrictHttpFirewall implementation by default.


Example 1: The following code relaxes the firewall policy to allow %2F and ; characters:

    <beans:bean id="httpFirewall" class="org.springframework.security.web.firewall.StrictHttpFirewall" p:allowSemicolon="true" p:allowUrlEncodedSlash="true"/>

Allowing potentially malicious characters can lead to vulnerabilities if these characters are incorrectly on inconsistently processed. For example, allowing semicolons enable path parameters (as defined in RFC 2396) which are not consistently processed by frontend web servers such as nginx and application servers such as Apache Tomcat. These inconsistencies may be used for path traversal attacks or access control bypasses.

Spring Security borrowed Ant path expressions to specify how to protect endpoints.

Example 1: In the following example, any endpoint that matches the "/admin" Ant path expression requires administrator privileges for access:

	<http auto-config="true">
        ...
        <intercept-url pattern="/app/admin" access="ROLE_ADMIN" />
        ...
        <intercept-url pattern="/**" access="permitAll" />
	</http>

However, if the protected endpoint is a Spring MVC endpoint, an attacker can bypass this control by abusing Spring MVC content-negotiation features. With Spring MVC users can specify how they want the resource served by either using the Accept header or by specifying the desired content-type using an extension. For example, you can request the /admin resource as a JSON document by sending the request to /admin.json.
Ant path expressions do not account for content-negotiation extensions, and therefore, the request does not match the /admin expression and the endpoint is not protected.

Spring Security uses an expression-based access control that lets developers define a set of checks that must be applied to every request. To determine if the access control must be applied to the request, Spring Security attempts to match the request with the request matcher defined for every security check. If the request matches, the access control is applied to the request. A special request matcher exists to always match against any requests: anyRequest(). Failing to define a fallback check that uses the anyRequest() matcher, might leave endpoints unprotected.

Example 1: The following code defines a Spring Security configuration that fails to define a fallback check:

	<http auto-config="true">
        <intercept-url pattern="/app/admin" access="ROLE_ADMIN" />
        <intercept-url pattern="/" access="permitAll" />
	</http>

In Example 1 above, current or future endpoints such as /admin/panel might be left unprotected.

Spring Security is configured with an overly permissive catch-all policy whereby a request that does not match any security expression is allowed access.

Example 1: The following code defines a Spring Security configuration that defaults to permit any unmatched requests:

	<http auto-config="true">
        ...
        <intercept-url pattern="/app/admin" access="ROLE_ADMIN" />
        <intercept-url pattern="/**" access="permitAll" />
	</http>

Even if this is currently a secure configuration, new private endpoints might be added to the application in the future. If developers forget to update the security policy, the default catch-all rule will allow public access to the new private endpoint.

Spring Boot applications can be configured to deploy Actuators, which are REST endpoints that allow users to monitor different aspects of the application. There are different built-in Actuators which may expose sensitive data and are labeled as "sensitive". By default all sensitive HTTP endpoints are secured such that only users that have an ACTUATOR role may access them.

This application is either disabling the authentication requirement for sensitive endpoints:

Example 1:

management.security.enabled=false

Or marking sensitive endpoints as non-sensitive:

Example 2:

endpoints.health.sensitive=false

Or a custom Actuator is set as non-sensitive:

@Component
public class CustomEndpoint implements Endpoint<List<String>> {

    public String getId() {
        return "customEndpoint";
    }

    public boolean isEnabled() {
        return true;
    }

    public boolean isSensitive() {
        return false;
    }

    public List<String> invoke() {
        // Custom logic to build the output
        ...
    }
}

Disabling the automatic escaping for HTML context in Spring tags may lead to the application being vulnerable to Cross-Site Scripting attacks.

Example 1: The following web.xml configuration instructs the application to disable automatic HTML escaping for Spring tags.

<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.0"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" metadata-complete="true">
    ...
	<context-param>
		<param-name>defaultHtmlEscape</param-name>
		<param-value>false</param-value>
    </context-param>
    ...
</web-app>

Cookies with names that start with the __Host- and __Secure- prefix must be set with the secure attribute. They must be set from a secure page (HTTPS). Additionally, a __Host- prefixed cookie must not have a domain attribute specified (so that it is not sent to subdomains) and the path attribute must be set to /. Violation of these rules can cause a browser to reject the cookie. Restricting a cookie's access to a secure channel protects it from being sent or being overwritten by a forged site over an unencrypted HTTP channel. Restrictions provided by the __Host prefix prevent a cookie from being accessed by a subdomain where the subdomain might be owned by different entities such as a shared blog platform.

The Spring Boot application has DevTools enabled. DevTools include an additional set of tools which can make the application development experience a little more pleasant, but DevTools are not recommended to use on applications in a production environment. As stated in the official Spring Boot documentation: "Enabling spring-boot-devtools on a remote application is a security risk. You should never enable support on a production deployment."

The Shutdown Actuator allows authenticated users to shut down the application. Even though it is configured by default as a sensitive endpoint and therefore authentication is required to use this endpoint, it is not a good practice to enable it without a strong reason since credentials may be weak or the application configuration can be modified to flag the actuator as non-sensitive.

Example 1: A Spring Boot application is configured to deploy the shutdown Actuator:

endpoints.shutdown.enabled=true

Spring Boot allows developers to enable admin-related features for the application by specifying the spring.application.admin.enabled property. This exposes the SpringApplicationAdminMXBean on the platform MBeanServer. Developers could use this feature to administer the Spring Boot application remotely, however this feature exposes an additional attack surface in the form of a remote JMX endpoint. Depending on the configuration of the MBeanServer the MBean can be exposed locally or remotely, and may or may not require authentication. In the worst case, attackers will be able to manage the application remotely, including shutting it down without any authentication. In the best case, the service will be as strong as the credentials used to protect the server.

Note: If using a JRE version vulnerable to CVE-2016-3427 (fixed in Java 8 Update 91, April 2016), an attacker will be able to pass any serialized Java object as the credentials, which may lead to arbitrary code execution when the remote JVM deserializes it.

Browsers support the HttpOnly cookie property that prevents client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without HttpOnly enabled, attackers have easier access to user cookies.

Example 1: When using the withHttpOnlyFalse() method of the Spring framework's CookieCsrfTokenRepository class, a CSRF cookie is generated without setting the HttpOnly property.

...
CookieCsrfTokenRepository c = CookieCsrfTokenRepository.withHttpOnlyFalse();
...

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data, session identifiers, or carries a CSRF token.
Example 1: The following configuration entry does not explicitly set the Secure flag for CSRF cookies, with the Spring framework.

...
CookieCsrfTokenRepository c = new CookieCsrfTokenRepository();
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers can then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

The Spring Expression Language (SpEL for short) is a powerful expression language that supports querying and manipulating an object graph at runtime. The language syntax is similar to Unified EL but offers additional features, most notably method invocation and basic string templating functionality.
Allowing unvalidated expressions to be evaluated will let an attacker execute arbitrary code.

Example 1: The application uses unvalidated data controlled by the user to create and evaluate a SpEL expression:

String expression = request.getParameter("input");
SpelExpressionParser parser = new SpelExpressionParser();
SpelExpression expr = parser.parseRaw(expression);

Example 2: The application uses unvalidated data controlled by the user in a Spring tag that perfoms double SpEL evaluation:

    <spring:message text="" code="${param['message']}"></spring:message>

A class annotated with @SessionAttributes will mean Spring replicates changes to model attributes in the session object. If an attacker is able to store arbitrary values within a model attribute, these changes will be replicated in the session object where they may be trusted by the application. If the session attribute is initialized with trusted data which the user should not be able to modify, the attacker may be able to conduct a Session Puzzling attack and abuse the application logic.

Example 1: The following controller contains a method which loads the user data into the session upon a successful login.

@Controller
@SessionAttributes("user")
public class HomeController {
    ...
    @RequestMapping(value= "/auth", method=RequestMethod.POST)
    public String authHandler(@RequestParam String username, @RequestParam String password, RedirectAttributes attributes, Model model) {
        User user = userService.findByNamePassword(username, password);
        if (user == null) {
            // Handle error
            ...
        } else {
            // Handle success
            attributes.addFlashAttribute("user", user);
            return "redirect:home";
        }
    }
    ...
}

A different controller handles the reset password feature. It tries to load the User instance from the session since the class is annotated with @SessionAttributes("user") and uses it to verify the reset password question.

@Controller
@SessionAttributes("user")
public class ResetPasswordController {

    @RequestMapping(value = "/resetQuestion", method = RequestMethod.POST)
    public String resetQuestionHandler(@RequestParam String answerReset, SessionStatus status, User user, Model model) {

        if (!user.getAnswer().equals(answerReset)) {
            // Handle error
            ...
        } else {
            // Handle success
            ...
        }
    }
}

The developer's intention was to load the user instance from the session where it was stored during the login process. However Spring will check the request and will try to bind its data into the model user instance. If the received request contains data that can be bound to the User class, Spring will merge the received data into the user session attribute. This scenario can be abused by submitting both an arbitrary answer in the answerReset query parameter and the same value to override the value stored in the session. This way, the attacker may set an arbitrary new password for random users.

A file disclosure occur when:
1. Data enters a program from an untrusted source.


2. The data is used to dynamically construct a path.

Example 1: The following code takes untrusted data and uses it to build a path which is used in a server side forward.

...
	String returnURL = request.getParameter("returnURL");
	return new ModelAndView(returnURL);
	...

If an attacker provided a URL with the request parameter matching a sensitive file location, they would be able to view that file. For example, "http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" would allow them to view the applicationContext.xml of the application.
After the attacker had the applicationContext.xml, they could locate and download other configuration files referenced in the applicationContext.xml or even class or jar files. This would allow attackers to gain sensitive infomation about an application and target it for other types of attack.

Content Security Policy (CSP) is a declarative security header that allows developers to dictate which domains the site is allowed to load content from or initiate connections to when rendered in the web browser. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code. An improperly configured header, however, fails to provide this additional layer of security. The policy is defined with the help of fifteen directives including eight that control resource access, namely: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src.

Each of these takes a source list as a value specifying domains the site is allowed to access for a feature covered by that directive. Developers may use wildcard * to indicate all or part of the source. None of the directives are mandatory. Browsers will either allow all sources for an unlisted directive or will derive its value from the optional default-src directive. Furthermore, the specification for this header has evolved over time. It was implemented as X-Content-Security-Policy in Firefox until version 23 and in IE until version 10, and was implemented as X-Webkit-CSP in Chrome until version 25. Both of the names are deprecated in favor of the now standard name Content Security Policy. Given the number of directives, two deprecated alternate names, and the way multiple occurrences of the same header and repeated directives in a single header are treated, there is a high probability that a developer might misconfigure this header.

Consider the following misconfiguration scenarios:

- Directives with unsafe-inline or unsafe-eval defeats the purpose of CSP.
- script-src directive is set but no script nonce is configured.
- frame-src is set but no sandbox is configured.
- Multiple instances of this header are allowed in same response. A development team and security team might both set a header but one may use one of the deprecated names. While deprecated headers are honored if a header with the latest name (that is, Content Security Policy) is not present, they are ignored if a policy with content-security-header name is present. Older versions only understand deprecated names, hence, in order to achieve desired support it is essential that the response include an identical policy with all three names.
- If a directive is repeated within the same instance of the header, all subsequent occurrences are ignored.

Example 1: The following django-csp configuration uses unsafe-inline and unsafe-eval insecure directives to allow inline scripts and code evaluation:

...
MIDDLEWARE = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

Spring enables developers to load Bean definitions from multiple resources including local files and remote URLs. If an attacker is able to control the contents of the Bean definition resource, they will be able to inject malicious Bean definitions which may execute arbitrary code upon their initialization.

Example: The following example loads a bean definition resource from a user-controlled location:

String beans = getBeanDefinitionFromUser();
GenericApplicationContext ctx = new GenericApplicationContext();
XmlBeanDefinitionReader xmlReader = new XmlBeanDefinitionReader(ctx);
xmlReader.loadBeanDefinitions(new UrlResource(beans));
ctx.refresh();

Developers often set cookies to be accessible from the root context path ("/"). This exposes the cookie to all web applications on the domain. Because cookies often carry sensitive information such as session identifiers, sharing cookies across applications can cause a vulnerability in one application to compromise another application.

Example 1:
Imagine you have a forum application deployed at http://communitypages.example.com/MyForum and the application sets a session ID cookie with the path "/" when users log in to the forum.

For example:

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setPath("/");

Suppose an attacker creates another application at http://communitypages.example.com/EvilSite and posts a link to this site on the forum. When a user of the forum clicks this link, the browser will send the cookie set by /MyForum to the application running at /EvilSite. By stealing the session ID, the attacker can compromise the account of any forum user that browsed to /EvilSite.

In addition to reading a cookie, it might be possible for attackers to perform a Cookie Poisoning attack by using /EvilSite to create its own overly broad cookie that overwrites the cookie from /MyForum.

All major browsers support the HttpOnly cookie property to prevent client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without the HttpOnly flag enabled, attackers have easier access to user cookies.
Example 1: The following code creates a cookie without setting the HttpOnly property.

  javax.servlet.http.Cookie cookie = new javax.servlet.http.Cookie("emailCookie", email);
  // Missing a call to: cookie.setHttpOnly(true);