Secure Coding Practices in Java – Challenges and Vulnerabilities

Some Stack Overflow recommendations on Java secure coding must not be trusted 100%. The future of Java security development is in building semi-automatic and automatic security bug-detection and patch-up tools.

Meng et al. analysed Stack Overflow posts related to java secure coding practices and unearthed the key topics, what users struggle with, and if or not the widely accepted answers truly adhere to the best java security practices.

Meng et al. crawled 22,195 posts on Stack Overflow that had the phrases “security” and “Java”. Further, they filtered the posts with no code snippets, those with negative votes and without accepted answers.

Another inspection resulted in 503 posts that were dated 2008-2016. Finally, the remaining posts were analyzed the security issues on Java secure coding that java developer experience, the evident programming obstacles and the vulnerabilities (insecure coding practices).

So, what do people ask about java on Stack Overflow?
A majority of the question were related to java functions implementation as opposed to questions in understanding the security design.

Further, Meng et al. analysed the ‘how do I…’ questions based on the platform under discussion: Spring Security, Java EE security, or Java platform security. Notably, Spring Security had the largest (56 percent) of the questions.

So, what were the key tops from the above classification, particularly implementation posts?

  • Spring Security: configuration, authorisation, and authentication.
  • Java EE security
  • Java platform: secure communication, access control, and cryptography.

Meng et al. noted that the volume and distribution of the questions kept growing and changing in the 2008-2016 research period.

From 2009-2011, a majority of the questions were on Java platform security. This changed from 2012 with a shift towards securing enterprise Java applications (such as Spring Security (over 50%) and Java EE security).

Key challenges (2008-2016)

Considering the five major topic areas (secure communication, cryptography, authentication, and Java EE security), Meng et al. conducted a thorough analysis to determine the common challenges.

Notable: The largest topic area in the Stack Overflow analysis is authentication. The authentication issue is unique to Spring Security. In this cases, developers wanted to know

i.         How to integrate Spring Security with various frameworks and application servers

ii.         Configuring Spring Security with Java (42 q’s) or XML (84 q’s)

iii.         Converting XML-built configurations to the Java- built ones.

1.     Integrating Spring Security

Originally, the Spring projects were mainly XML-built, a situation that has since changed. Currently, Spring Security supports the Java-built configurations since the 2013 release of Spring Security 3.2.0. However…..

….still there exists many annotations & APIs of methods, classes, and fields that can stipulate different configuration selections …. Subtle requirements and implicit constraints are not adequately documented.

(Check the latest guides in 5.0.6 release. However, when beginning from scratch, check the Spring Boot way).

In addition, developers struggle with conveying the previous XML-built projects to utilise the Java configuration.

Cryptography (Java platform)

In Cryptography, developers struggle with challenges in implicit constraints, poor error messages, and encrypting and decrypting data using different languages.

Notably, cryptography posts mainly related to key generation and their usage. The developers reported facing implicit API-usage constraints, cross-language handling of data, and clueless-error messages.

Access control

The Access control posts on Stack Overflow were related to how to restrict some untrusted code to access specific methods, classes, and packages.

Further, Meng et al. noted 9 posts related to applets, which highlighted the limitation on the study. Notably, in 2018, applets are a “don’t use”.

Security communication

On Security communication, most posts related to how to establish SSL or TLS connections. The process is extensive and hence most developers tended to accept broken solutions with the goal of bypassing some security verification.


Again, we repeat our initial question: Does Stack Overflow offer good java advice? Meng et al.’s initial response is… Yes…….sometimes.

However, Meng et al. discovered security vulnerabilities in the Stack Overflow’s accepted answers for three frequent topic areas:

i.         password hashing

ii.         SSL/TLS,

iii.         Spring Security’s csrf()

The common theme is the questions was “security policy is interrupting me from doing xxxxx,” with the answer on Stack Overflow commonly being “disable security!”

Spring Security will, by default, enable CSRF protection and its associated token must be included in the DELETE, PUT, POST, and PATCH methods. However, don’t disable the CSRF protection!

On the SSL/TSL issues, certification verification was a key concern. Notably, disabling your validation process for SSL certificate would hinder the secure communication protocol. This would make the client be exposed to the man-in-the-middle (MITM) attacks.

On password hashing, Stack Overflow had notably outdated advice. Meng et al. reported that 50% of the password hashing posts endorsed vulnerable solutions as the right answers. This shows that developers lacked the most up to date secure programming practices.


Meng et al. and companies building java development software make the following recommendations:

i.         As a developer, undertake security testing to determine if all features are working as required. However, do not disable security checks – even in what is considered line ‘temporary’ fix in the test or dev. Check that the Stack Overflow is secure and up-to-date.

ii.         Tool builders need to design tools that will automatically diagnose security errors, discover code with bugs, and recommend solutions or patches.

Finally, the future of Java security development is in building semi-automatic and automatic security bug-detection and patch-up tools.

0 0 votes
Article Rating
Inline Feedbacks
View all comments