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.
This post will give your a list of actions and quick guide how to optimize your website and increase performance significantly. following guidelines are:
Reduce required requests: Less number of http requests means less overhead on the page.
Use css for your main images: CSS Sprites is wonderful solution for merging icons and lots of small images into one. This reduce number of http requests in every page of the website.
Use a faster web server: Apache is standard solution however, there are solution which provides better speed. Look for more details.
Implement caching: It’s common to implement caching however, you should look for caching at multiple layers. Web-server caching, CDN caching and end user browser caching. All of them gives extra mileage in performance.
Enable compression: Compression(GZIP) is common and must be implemented in every content transfer happens from client to server. Read about it in below articles.
Eliminate plugins: Use standard libraries and try to avoid building wheel for any new problem. Libraries help in providing optimized solutions. Just look for security before using it though.
Use a top tier host
Use a content delivery network: CDN is good at serving static content and improves overall performance of the application. you must implement it.
Employ anycast dns: Anycast is CDN of DNS. It means all DNS resolution happens very quickly and available any cast DNS server helps resolve DNS queries quickly.
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.
“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.
Let’s consider a scenario of a web application which has common copyright & footer links and developer wants this footer to be displayed in every page. One solution is to add copyright & footer links in every page manually or use server side include.
What is Server side include?
Server side include is a web server feature that allows developers to dynamically generate web content by using “#” directives without having to do it manually. The server searches for the SSI directives in the HTML code and executes them sequentially. These directives may include shell commands or files or CGI variables that have to be replaced with their value. After executing all the directives, the HTML is finally served at the requestor. This saves a lot of time, makes the code more readable and easy to maintain. The following are some sample directives: <! — #include virtual=“/footer.html” →
Server Side Include(SSI) Security vulnerability
Server-Side Include (SSI) injection vulnerabilities arise when an application incorporates user-controllable data into response that is then parsed for Server-Side Include directives. If the data is not strictly validated, an attacker can modify or inject directives to carry out malicious actions.
SSI is a form of attack that can be used by attackers to compromise web applications having SSI directives. Such applications often accept user input and render the same in their pages. This functionality is taken advantage by the attacker who can inject a malicious SSI directive as input. As a result, the hacker can add, alter or delete files on the server, execute shell commands and even gain access to sensitive files like “/etc/passwd”.
If possible, applications should avoid incorporating user-controllable data into pages that are processed for SSI directives. In almost every situation, there are safer alternative methods of implementing the required functionality. If this is not considered feasible, then the data should be strictly validated. Ideally, a whitelist of specific accepted values should be used. Otherwise, only short alphanumeric strings should be accepted. Input containing any other data, including any conceivable SSI metacharacter, should be rejected.
In any web application, Cookies play a very significant behavior of the application. Whether user experiences, personalization, analytics or session management, Cookies are part of every web module. The importance of cookies in a web application is so critical that privacy regulation put clause about cookies & web apps. And, Every web application must alert to the user.
Importance of HttpOnly Flag in Cookie
Should Every cookie have HttpOnly Flag set?
There is usually no good reason not to set HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie’s value.
So, Setting of HttpOnly flag is always conditional & you should evaluate when to set.