There is no such thing as total security either in real life or online. All security can do is make the cost of defeating it greater than the reward. Security measures, while not worthless, can only only reduce the risk.
For Cyber security some HTTP headers can be used to reduce the risk and are supported by all major modern browsers. A list of useful headers is given in 
Three defences will reduce risk considerably
a. Setting the HttpOnly cookie flag
b. Setting the X-Xss-Protection: 1
c. Using Content-Security-Policy
None of these are magic bullets but they are valuable parts of a total security package.
The HTTP only cookie flag
The HTTP only flag is like a Yale lock. It keeps out the amateurs and the lazy bad guys, but not the determined attacker. One common cross site scripting attack is cookie theft especially a session ID and one way to reduce this risk is to use the HTTP only flag which is supported by all modern browsers.
The simple way to do this is to append “; HTTPOnly;” to the cookie value.
It is possible to get past this flag by using a combination of cross site scripting and cross site request forgery to force users to generate requests , which means attackers do not need to access the cookie. Other techniques to get round HTTP only have been considered such as using the HTTP TRACE verb. But this flag is cheap to use and stops simple attacks.
In servlet 3.0 you can configure this in web.xml as follows
< hTTP-only> true </ hTTP-only>
</ session-config >
Older versions of tomcat, That is the full version 7 only allow this to be set in the server.xml file
In tomcat 7.0 this attribute is enabled by default, which means your JsessionID Will be HTTP only unless you change the default behaviour in server.xml as well.
You can also programmatically add an HTTP only cookie directly to the request as follows
String cookie = "mycookie = test; secure; HTTP only";
Response.Addheader(" set-cookie", cookie);
The servlet 3.0 API is updated with the convenience method set HTTP only for adding this flag.
The Cross Site Scripting header
X-XSS-Protection is a header first created by Microsoft to block common reflected Cross site scripting. It's enabled by default in Internet Explorer Safari and chrome but not in Firefox.
There are three modes:
1) the value of one is the default behaviour and tells the browser to modify the response to block deleted cross site scripting attacks
2) the value of zero Will disable cross site scripting protection completely
3) specifying the value of one and mode = block tells the browser to block the attack and also prevent the page rendering entirely. This means users will see only an empty browser page.
This mode should only be used after usability testing.
You can also set this header in Java
X-XSS-Protection: 1; mode=block
response.addheader(" X-XSS-protection"," 1";mode=block);
It may be better to set this from the web server configuration, which will vary with the server 
Content Security Policy
CSP is not meant to be a frontline defence against attacks, but a defence in depth to minimise harm caused by content injection attacks 
CSP prevents man in the middle attacks, which are undetectable over HTTP, as well as most cross site scripting attacks, other than through user input, which can be escaped before use though with DOM injection, attacks may still be possible 
How To set up CSP
Include a CSP header in your response which looks like (note the colon)
where policy is a string of policy directives separated by semicolons.
A policy directive is a policy directive name followed by a list of urls separated by spaces
Content-Security-Policy: policy-directive_1 url1 url2....., policy directive2 url3 url3; etc
A full list of policy directives is given in  . The most important is default-src. The default-src directive specifies default sources for types of content. It is not obligatory but is a good idea. It is also a good idea to include the object-src directive which specifies the sites from which to accept scripts. The unsafe-in-line directive should not be used without a very good reason.
To enforce the default-src directive, the page or site must enforce the following directives:
If not specified explicitly in the policy, the directives listed above will use the default sources which may default to 'none' or 'all' depending on the browser.
1.Content-Security-Policy: default-src https://onlinebanking.honestbankstraightup.com
Documents can only be accessed over https from the stated url.
2. Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
Content is only allowed from the document#s original host with these exceptions
images can come from anywhere
media can only come from media1.com and media2.com
scripts can only come from userscripts.example.com
- Content-Security-Policy-Report-Only: default-src ='self' report-uri=http:localhost/policyviolations.htmlAction will not be taken but violations will be reported on the specified URI and will showa) document-uri: the document where the attack took place,b) violated-directive : which directive was violatedc) script-sample: a portion of the XSS attackd) line-number: the line number for debugging and research.4. response.setHeader(“Content-Security-Policy-Report-Only”, “default-src 'self', “report-uri http://someaccessibleuri
Note that you can have both the CSP header and the CSP-Report-Only header active so you can test only one policy at a time.
To reduce XSS risk
Set-cookie HTTP-only to prevent it session-hijacking
set XSS-Protection: 1
Plan to use Content-Security-Policy
The HTTP flag is not a header but setting ti will prevent a lot of common XSS attacks.
The Xss-Protection header is not supported by all browsers but is enabled by default on IE, Chrome and Firefox and prevents reflected XSS attacks
- https://developer.chrome.com/extensions/contentSecurityPolicy Style changes needed with content Security policy
- https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-1.0-specification.html Content Security policy specification