We use cookies to ensure you get the best experience on our website.Read moreRead moreGot it

close
  • Products
    • Products
      • Snyk Open Source (SCA)
        Avoid vulnerable dependencies
      • Snyk Code (SAST)
        Secure your code as it’s written
      • Snyk Container
        Keep your base images secure
      • Snyk Infrastructure as Code
        Fix misconfigurations in the cloud
      • Snyk Cloud
        Build, deploy, and stay secure
    • Solutions
      • Application security
        Build secure, stay secure
      • Software supply chain security
        Mitigate supply chain risk
      • Cloud security
        Build and operate securely
    • Platform
      • What is Snyk?
        Developer-first security in action
      • Developer security platform
        Modern security in a single platform
      • Security intelligence
        Comprehensive vulnerability data
      • License compliance management
        Manage open source usage
      • Snyk Learn
        Self-service security education
  • Resources
    • Using Snyk
      • Documentation
      • Vulnerability intelligence
      • Product training
      • Customer success
      • Support portal & FAQ’s
      • User hub
    • learn & connect
      • Blog
      • Community
      • Events & webinars
      • DevSecOps hub
      • Developer & security resources
    • Listen to the Cloud Security Podcast, powered by Snyk
  • Company
    • About Snyk
    • Customers
    • Partners
    • Newsroom
    • Snyk Impact
    • Contact us
    • Jobs at Snyk We are hiring
  • Pricing
Log inBook a demoSign up
All articles
  • Application Security
  • Cloud Native Security
  • DevSecOps
  • Engineering
  • Partners
  • Snyk Team
  • Show more
    • Vulnerabilities
    • Product
    • Ecosystems
Java configuration
Application SecurityEcosystems

Java configuration: how to prevent security misconfigurations

Brian VermeerFebruary 26, 2021

Java configuration is everywhere. With all the application frameworks that the Java ecosystem has, proper configuration is something that is overlooked easily. However, thinking about Java configuration can also end up in a security issue if it is done in the wrong way. We call this misconfiguration. Security misconfiguration is part of the infamous OWASP top 10 vulnerability list and has a prominent spot on place 6.

Wrongly configuring your Java application can lead to security issues. First of all, defaults may turn out to be convenient as it makes a library or framework work instantly. Nevertheless, these defaults are not always the safest Java configuration as they might disclose information that is both great for debug reasons, but also disclose information that is interesting for intruders.

Java configuration issues

One of the most famous examples is the misconfiguration of the XML parsers in Java. In the 

10 Java security best practices cheatsheet, we already discussed the possibility of XXE attacks because of misconfiguration. I also explained in this youtube video that the default Java configuration for all XML parsers is vulnerable. By simply putting in the correct configuration and disabling external entities, we prevent possible XXE attacks.

Another example is proper Java configuration for your error handling. No matter how well written your Java web application is, somehow, an exception will turn up eventually. If an exception is not uncaught—and, therefore, not handled in, for instance, a JSP application—the default behavior is to display the exception and the stack trace in the browser.

This doesn’t only show that you are using Java, but also what kind of internal package you utilize. In many cases, these exceptions may also include specific information like IDs. None of this information is useful for the user and even harms the user experience. More importantly, this exposes information that might be valuable to people who have less good intentions when using your application.

By configuring for error pages, as seen below, you redirect the user based on a return code or an exception-type without displaying internal information.

<error-page>
   <error-code>401</error-code>
   <location>/ErrorPage401.jsp</location>
</error-page>

<error-page>
   <exception-type>java.lang.Throwable</exception-type>
   <location>/ErrorPage.jsp</location>
</error-page>

Configuration issues in Java libraries and frameworks

Using java libraries and third-party packages to do some of the heavy lifting for you is a great approach. However, you should be aware that configuring these tools appropriately is crucial for your security strategy. Luckily, most library maintainers make sure that the default values are entirely secure. However, changing them might look convenient but can get you in a whole lot of trouble.

Let’s look at Jackson, for instance, a well-known library that is widely used to parse JSON to POJOs and visa-versa. When misconfiguring the Jackson library and allowing “default typing”, you can deserialize arbitrary objects that are available on the classpath. This might lead to the same sort of deserialization vulnerabilities that existed in Java’s native serialization.

Thankfully, by default, this feature is disabled and, therefore, a deserialization issue with code execution, for example, is far less likely to happen. However, if you change this configuration in your java application and enable it, you might introduce unwanted security risks.  

Spring configuration issues

Spring Framework is the most popular application development framework for Java. The main feature of the Spring Framework is dependency injection or inversion of control. 

Spring Boot is basically an extension of the Spring Framework. It allows us to build a stand-alone application with minimal or zero configurations. Spring Boot has a number of starter components that bring in features by simply importing the correct dependency.

Spring Boot Actuator

By adding the spring-boot-starter-actuator dependency to your manifest, Spring Boot Actuator gives you a number of endpoints that are interesting for maintainers and developers. 

You can think about the env endpoint, which shows you environment properties, for example, what’s in the classpath, the beans (all Spring beans in the app),the threaddump, and shutdown endpoint. Check the complete list in the documentation. 

By default, all these endpoints are enabled but, luckily, not all are exposed via HTTP by default. Nevertheless, configuring these default endpoints and enabling them for web or JMX is easy. Also, it an easy thing to turn off when going to production. Having the following line in your properties exposes all endpoint (except the shutdown endpoint) to the web:

management.endpoints.web.exposure.include=*

Be aware to only enable and expose the endpoints in production that you actually need. Preferable, by blocking everything except a few, instead of the other way around.

management.endpoints.enabled-by-default=false
management.endpoint.info.enabled=true
management.endpoints.jmx.exposure.include=health,info
management.endpoints.web.exposure.include=env,beans

In addition, make sure that the endpoints are only available by authorized systems and people by including and configuring spring-security correctly for these endpoints.

Spring Boot developer tools

As the name suggests this Spring Boot component is an additional set of tools that is helpful during development and makes the application development experience a little easier. Things like automatic restarts, remote debugging, and remote updating make this feature set extremely helpful for development.

According to the Spring documentation this is the default behavior: “Developer tools are automatically disabled when running a fully packaged application. If your application is launched from java -jar or if it is started from a special classloader, then it is considered a “production application”. 

However by setting the property spring.devtools.restart.enabled you can overwrite the safe default behavior. 

Conclusion

In general, we should be aware that your Java application configuration is just important as writing the code itself. When using frameworks and libraries you should be aware of what the default configuration settings are and if certain changes have security implications.

Giving too much information away by leaving debug logging or enabling endpoints or features that are in place for development purposes will hurt your application and your company. 

This holds true for both application frameworks and libraries, but also for the settings of your webserver. Remind yourself that exposing information might not be harmful at first sight, but if you combine all these bits and pieces of information you will give an attacker enough ammo to do something, potentially, malicious.

Using libraries, frameworks, and even application servers is very useful but you should be aware of how they work. Java configuration and misconfiguration is a serious thing. Make sure that you are not accidentally giving people access to your application because you forgot to set a specific property in your configuration.

Discuss this blog on Discord

Join the DevSecOps Community on Discord to discuss this topic and more with other security-focused practitioners.

Go to Discord
Footer Wave Top
Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment
Develop Fast.
Stay Secure.
Snyk|Open Source Security Platform
Sign up for freeBook a demo

Product

  • Developers & DevOps
  • Vulnerability database
  • API status
  • Pricing
  • Test with GitHub
  • IDE plugins
  • What is Snyk?

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Japanese site
  • Audit services
  • Web stories

Company

  • About
  • Snyk Impact
  • Customers
  • Jobs at Snyk
  • Snyk for government
  • Legal terms
  • Privacy
  • Press kit
  • Events
  • Security and trust
  • Do not sell my personal information

Connect

  • Book a demo
  • Contact us
  • Support
  • Report a new vuln

Security

  • JavaScript Security
  • Container Security
  • Kubernetes Security
  • Application Security
  • Open Source Security
  • Cloud Security
  • Secure SDLC
  • Cloud Native Security
  • Secure coding
  • Python Code Examples
  • JavaScript Code Examples
Snyk|Open Source Security Platform

Snyk is a developer security platform. Integrating directly into development tools, workflows, and automation pipelines, Snyk makes it easy for teams to find, prioritize, and fix security vulnerabilities in code, dependencies, containers, and infrastructure as code. Supported by industry-leading application and security intelligence, Snyk puts security expertise in any developer's toolkit.

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Japanese site
  • Audit services
  • Web stories

Track our development

© 2022 Snyk Limited
Registered in England and Wales
Company number: 09677925
Registered address: Highlands House, Basingstoke Road, Spencers Wood, Reading, Berkshire, RG7 1NT.
Footer Wave Bottom