Category Archives: web application security

When & How to use Spring boot @Transactional?


The @Transactional annotation is probably the most randomly used annotation in the whole Java development world – and it’s terrifying!

There are many misconception about how & and where to use @Transactional annotations in spring boot application. I came across this awesome tutorial and it is worth reading it.

Common pitalls are:

  • Pitfall #1: Redundant @Transactional or JPA calls
  • Pitfall #2: @Transactional ignored?
  • Pitfall #3: @Transactional(readOnly = true)
  • Pitfall #4: Rollbacks
  • Pitfall #5: Propagation modes and isolation levels


How to use Apache HttpClient securely?

Every java developer in the world knows and uses Apache HttpClient Library. This is one of the library can be found in every enterprise application. However, we often miss the security implications of using any library. Every library comes with security feature but it is always developer responsibility to incorporate security in every HTTP API integration.

HttpClient provides full support for HTTP over Secure Sockets Layer (SSL) or IETF Transport Layer Security (TLS) protocols by leveraging the Java Secure Socket Extension (JSSE). JSSE has been integrated into the Java 2 platform as of version 1.4 and works with HttpClient out of the box. On older Java 2 versions JSSE needs to be manually installed and configured

Standard SSL in HttpClient

Basically, every JVM has trust-store and JSSE is already installed then you do not need to worry about passing custom certificate in HttpGet request. Java takes care of it. Take a look in below code.

HttpClient httpclient = new HttpClient();   
GetMethod httpget = new GetMethod("");    
try {      
httpclient.executeMethod(httpget);     System.out.println(httpget.getStatusLine());   
finally {     httpget.releaseConnection();   }

So, in simple terms if you application triggers a Get request then first HTTPS handshake happens between client & server. Server passes the certificate and client validates in JVM trust code. If you like to understand in graphics you can watch below video.

How to use custom SSL certificates in HttpGet Request?

Read the full document to understand it. Click here

Example code copied from the document.

import org.apache.http.HttpEntity;
import org.apache.http.HttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.conn.ssl.NoopHostnameVerifier;
import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClientBuilder;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.ssl.SSLContextBuilder;
import org.apache.http.ssl.SSLContexts;
import org.apache.http.util.EntityUtils;

public class ClientCustomSSL {
   public final static void main(String[] args) throws Exception {

      //Creating SSLContextBuilder object
      SSLContextBuilder SSLBuilder = SSLContexts.custom();
      //Loading the Keystore file
      File file = new File("mykeystore.jks");
      SSLBuilder = SSLBuilder.loadTrustMaterial(file,

      //Building the SSLContext usiong the build() method
      SSLContext sslcontext =;
      //Creating SSLConnectionSocketFactory object
      SSLConnectionSocketFactory sslConSocFactory = new SSLConnectionSocketFactory(sslcontext, new NoopHostnameVerifier());
      //Creating HttpClientBuilder
      HttpClientBuilder clientbuilder = HttpClients.custom();

      //Setting the SSLConnectionSocketFactory
      clientbuilder = clientbuilder.setSSLSocketFactory(sslConSocFactory);

      //Building the CloseableHttpClient
      CloseableHttpClient httpclient =;
      //Creating the HttpGet request
      HttpGet httpget = new HttpGet("");
      //Executing the request
      HttpResponse httpresponse = httpclient.execute(httpget);

      //printing the status line

      //Retrieving the HttpEntity and displaying the no.of bytes read
      HttpEntity entity = httpresponse.getEntity();
      if (entity != null) {

Every Developer must read it: [SWAT] Checklist

Securing Web Application Technologies [SWAT] Checklist

The SWAT Checklist provides an easy to reference set of best practices that raise awareness and help development teams create more secure applications. It’s a first step toward building a base of security knowledge around web application security. Use this checklist to identify the minimum standard that is required to neutralize vulnerabilities in your critical applications.


Web Security: Importance of Strict-Transport-Security in any website


The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

The HTTP Strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.

The Strict-Transport-Security header is ignored by the browser when your site is accessed using HTTP; this is because an attacker may intercept HTTP connections and inject the header or remove it. When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header.


Good Read: MIME Sniffing in Browsers and the Security Implications

Whenever a website in opened in a browser, there are many tasks that are being silently performed in the background. One of those tasks is fetching resources such as images, stylesheets and JavaScript from different domains on the internet and then parsing those resources.

For example, a browser fetches an image from remote server and renders it for display when it encounters an <img> tag with src attribute in an HTML document. Browsers handle these resources based on their MIME type, and a browser’s behavior can be guided by the X-Content-Type-Options HTTP header returned by the web server.

In this post, we are going to look at security risks for an application that does not make use of this header. Specifically, we will look at the conditions under which exploitable vulnerabilities arise.

MIME Sniffing Introduction

MIME stands for “Multipurpose Internet Mail Extensions.” MIME was originally defined to support non-ASCII text and non-text binaries in email. However, the content types defined in MIME standard are used in HTTP protocol to define the type of content in a request or response. 

A browser usually identifies a resource’s MIME type by observing the Content-Type response header in an HTTP response. 

Figure 1:Content-Type response header for an HTML page from

Sometimes, developers set values for Content-Type headers that are not appropriate for the response’s content. For example, if a server sends text/plain value for a JavaScript resource, it is a mismatch. As per web standards, text/plain is not a valid JavaScript MIME type. However, browsers may parse and render such misrepresented resources so that the website will operate as intended. This is where MIME sniffing comes into picture. An example has been given in Figure 2.  

Figure 2: A JavaScript resource served with incorrect Content-Type value

 “MIME sniffing” can be broadly defined as the practice adopted by browsers to determine the effective MIME type of a web resource by examining the content of the response instead of relying on the Content-Type header. MIME sniffing is performed only under specific conditions. Please note that MIME sniffing algorithms vary by browser. A MIME sniffing standard has been defined on the Web Hypertext Application Technology Working Group (WHATWG) website.