The world of security, especially Web security, is a very complex and extensive knowledge domain to attempt to master-one where the consequences of failure can be extremely high. Practitioners can spend years studying this discipline only to realize that the more they know, the more they realize they need to know.
In fact, the challenge may seem to be so daunting that many choose to shy away from the subject altogether and deny any responsibility for the security of the system they are working on.
A Web application can receive input data in a number of ways (for example, from visible and hidden HTML form fields, cookies, and HTTP headers/URLs). Because an attacker could disable or modify any client-side validation routine, none of this input data should be processed until it has first been reexamined by a server-side validation routine.
HTTP headers are not normally used by Web applications that work with Web browsers. They are sometimes used with applications that have thick-clients that use the HTTP protocol, however. This is a small percentage of Web applications. However, we include it in this section to illustrate that any input can be modified. Cookies are perhaps the most well-known headers, but authorization schemes can also be based on the “Location:” and “Referer:” (the HTTP definition misspells the term) headers. The application might also rely on custom headers to track a particular attribute of the user.
When a browser submit a request for a page to the apache web server, it will send back the response data as well as response headers. The response headers usually contains important information like response Status, Content Type, Date and Time of Response etc. However, sometimes if you don’t configure the web server properly, it will expose some important information about the server in the response header.
Embed the following piece of code in the end of your .htaccess file which adds an extra layer of security in your website and prevents your site from various type of attacks such as Clickjacking, Cross Site Scripting etc:
You may also like:
# BEGIN HTTP Headers
Header always set X-Content-Type-Options “nosniff”
Header unset X-Powered-By
Header always set Access-Control-Allow-Credentials “true”
Header always set Access-Control-Allow-Methods “GET, POST, OPTIONS”
Header always set Access-Control-Allow-Headers “Origin”
Header always set Content-Security-Policy “default-src ‘self’; script-src ‘self’; style-src ‘self’ ‘unsafe-inline’; img-src ‘self’; connect-src ‘self’; object-src ‘self’; frame-src ‘self’;”
Header always set Referrer-Policy “no-referrer-when-downgrade”
Header always set Strict-Transport-Security “max-age=31536000; includeSubDomains”
Header always set X-Frame-Options “DENY”
Header always set X-XSS-Protection “1; mode=block”
Header always set X-UA-Compatible “IE=edge,chrome=1”
# END HTTP Headers
# BEGIN Cookie Security
php_flag session.cookie_httponly on
php_flag session.cookie_secure on
# END Cookie Security
- Top 7 Commercial Linux Distributions
- Why Do I Need a Website?
- Reinforcement Learning in Real-world Applications: The Latest Successes and Challenges
- Various Python Libraries for developing RESTful APIs
- Top 7 NodeJS Frameworks You Need To Know
- How Buying Instagram Followers Can Help Businesses Soar
- How To Find Gaps In Your Cybersecurity And How To Address Them
- How to close the site from indexing using robots.txt
- Internet Security With VPN – Why Do You Need It
- How to Fix The DLL Missing Error in Windows 7?