How to Restrict Unauthorized Request and Response in Java Development

Aegis SoftTech team has resolved the security issues with Java development team in India and made the application safe using different web security rules. They also restricted unauthorized request and response by implementing Security and filters. Here we share the process of restricting such requests and responses for our Java community below.

To make our domain application safe with different web security rules defines in OWASP because application is for multiple user and different user have different role and permission. To restrict unauthorized request and response we have implemented Security and Filters.

1. Http Strict Transport Security :

  • HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.
  • Simple example using max-age:

httpServletResponse.setHeader(“Strict-Transport-Security”,”max-age=31536000 ; includeSubDomains”);

2. Host Response Header :

  • If you are using name-based virtual hosts, the Server Name inside a section specifies what hostname must appear in the request’s Host: header to match this virtual host.

3. X-Frame-Options Response Header :

  • The X-Frame-Options http response header can be used to indicate whether or not a browser should be allowed to render a page in

a <frame>, <iframe> or<object> . We can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.

There are three possible values for X-Frame-Options:


The page cannot be displayed in a frame, regardless of the site attempting to do so.


The page can only be displayed in a frame on the same origin as the page itself.


The page can only be displayed in a frame on the specified origin.

  • Simple example using sameorigin:

httpServletResponse.setHeader(“X-Frame-Options”, “SAMEORIGIN”);

4. Pragma :

  • The Pragma: no-cache header field is an HTTP/1.0 header intended for use in requests.
  • It is for Cache Control, it does not have to be ONLY for cache-preventing, it can also be used to say “You can cache this
  • Simple example:

httpServletResponse.setHeader(“Pragma”, “no-cache”);

5. Cache-Control :

  • Cache-Control response headers, to give Web publishers more control over their content, and to address the limitations of Expires.
  • Simple example:

httpServletResponse.setHeader(“Cache-Control”,”max-age=0,no-cache, no-store, must-revalidate”);

no-cache —> forces caches to submit the request to the origin server for validation before releasing a cached copy, every time. This is useful to assure that authentication is respected (in combination with public), or to maintain rigid freshness, without sacrificing all of the benefits of caching.

no-store —> instructs caches not to keep a copy of the representation under any conditions. which will prevent request and response from being stored by the cache.

max-age=[seconds] —> specifies the maximum amount of time that a representation will be considered fresh. Similar to Expires, this directive is relative to the time of the request, rather than absolute. [seconds] is the number of seconds from the time of the request you wish the representation to be fresh for.

must-revalidate —> tells caches that they must obey any freshness information you give them about a representation. HTTP allows caches to serve stale representations under special conditions; by specifying this header, you’re telling the cache that you want it to strictly follow your rules.

6. Expires :

  • Expires response headers gives the date/time after which the response is considered stale.
  • Simple example to set date header for expires:

httpServletResponse.setDateHeader(“Expires”, 0);

7. X-XSS-Protection :

  • Cross-site scripting (XSS) enables attackers to inject client-side script into Web pages viewed by other users.
  • A cross-site scripting enabled by default anyway, so the role of this header is to re-enable the filter for this particular website if it was disabled by the user.
  • A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy

0 -> Disables the XSS Protections offered by the user-agent.

1 -> Enables XSS protections and instructs the user-agent to block the response in the event that script has been inserted from user input, instead of sanitizing.

  • Simple example:

httpServletResponse.setHeader(“X-XSS-Protection”, “1; mode=block”);

8. X-Content-Type-Options:

  • X-Content-Type-Options:is an IE- and Chrome-specific header that is designed to defend against MIME content-sniffing attacks. MIME content-sniffing attacks are a risk when you allow users to upload content (e.g., images, documents, other files) to your website, where they can be downloaded by other users.
  • It prevents the browser from doing MIME-type sniffing.
  • Simple example:

httpServletResponse.setHeader(“X-Content-Type-Options”, “nosniff”);

All these 8 security options will help you in restricting unauthorized response and request in Java web application development. Aegis SoftTech professionals are efficiently using these security options to make their domain safer than before. We have shared these points to help worldwide java developers and development community to bring flawless secure app solutions for users.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s