Adding an extra layer of security using some of the newest methods and technologies can protect your application from unwanted attacks and prevent data loss. By taking your web application’s security to the next level, you provide your users with a safe and problem-free environment. If your users don’t have to worry about data breaches that put their personal information at risk, they will enjoy a care-free experience on your site or app.
Considering that earning the consumers’ trust is essential for brands nowadays, enhancing your app’s security is an excellent first step. That is why we decided to share some useful methods to boost your web app’s security and raise your brand’s credibility.
Now, without further ado, let’s get into it!
Using CakePHP Component to Boost Your Web Application’s Security
The security component in CakePHP makes implementing various security integrations into your applications quite easy. It provides built-in methods for things like:
- Restricting which HTTP methods your application accepts.
- Implementing form tampering protection.
- Requiring the use of SSL.
- Limiting cross controller communication.
This component automatically offers protection from form tampering. That includes hidden token fields that are automatically inserted into forms and checked by the security component.
If the security component restricts or prevents a specific action, it will black-hole it as an invalid request and return a 400 HTTP error.
You can also use this component to ensure you only accept actions using SSL, which is quite a widespread practice nowadays. We can say with certainty (as our app also uses this) that this method is an excellent first layer of web application security.
Another feature of this component is that it allows only a specific list of controllers to access the requested controller. So if a controller inside the application is not on the security component’s whitelist, its request will be denied. Alternatively, you can choose to restrict access only to specific actions inside the controller, which you can use to control the cross controller requests.
Combating Form Tampering Using CakePHP
By default, the security component prevents users from tampering with forms. That’s what makes it so potent at preventing the following:
- Adding unknown fields in the form.
- Removing fields from the form.
- Modifying values in hidden inputs inside the form.
Using the FormHelper to track the fields in a form will prevent all of the above. The component will combine all of this data and turn it into a hash. Once the form is submitted, the security component will build the same data using the POST from the form and compare the hash.
Do note that you can remove some of the fields from the validation and exclude them from POST validation if you wish.
Cross-Site Request Forgery Prevention With CakePHP
Cross-site request forgery, also known as a one-click attack or session riding, is a malicious exploit of a website where an end-user executes unwanted actions on a web application where it is authenticated.
A malicious website can transmit such commands in multiple ways. Some of them are specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests. All of these can cause harm without any user interaction or knowledge. Luckily, Cake’s CSRF component can help protect against these attacks.
Firstly, this component sets a cookie on the user’s browser. Then, once the user creates a form, the component adds a hidden field containing the CSRF token. If the request is POST, PUT, DELETE, or PATCH, the component will compare the request data with the cookie value. If they mismatch, the component will deny the request.
CSRF tokens can be submitted through a special X-CSRF-Token header to add CSRF protection to AJAX requests. Using a header often makes it easier to integrate a CSRF token with JavaScript-heavy applications or XML/JSON based API endpoints.
Using Server-Side Implementations to Boost Your Web Application’s Security
When it comes to enhancing your app’s security using various server-side implementations, there are three useful methods you could use:
- X-Frame Options
- Content Security Policy
- Strict-Transport-Security
Let’s look at what lies behind each of them in more detail!
X-Frame Options
The X-Frame-Options HTTP response header is just one of the measures you can use to indicate whether a browser should be allowed to render a page in a <frame>, <iframe>, <embed>, or <object>. Sites can use this technique to avoid click-jacking attacks by ensuring that their content is not embedded into other sites. However, this added security is only present if the user accessing the document uses a browser that supports X-Frame-Options.
There are two possible directives for X-Frame-Options:
- X-Frame-Options: DENY
- X-Frame-Options: SAMEORIGIN
If DENY is specified, all attempts to render a page inside a frame will fail, including those on the same domain.
If SAMEORIGIN is set, it will allow page rendering inside of a frame hosted on the same domain as the parent page.
Content Security Policy
CSP or Content Security Policy is another method that adds security to your application; it helps detect attacks like Cross-Site Scripting (XSS) and data injection attacks. These attacks can be used for data theft, site defacements, or the distribution of malware.
CSP is fully backward compatible so that the browsers that don’t support it can still work with servers that implement it and vice-versa. If a site doesn’t offer the CSP header, the browser will use the standard same-origin policy. Also, browsers that don’t support CSP will ignore it and default to the standard same-origin policy too. That is why you need to configure the web server to enable CSP to return the Content-Security-Policy HTTP header.
You can use the <meta> element to configure a policy like in the following example:
<meta http-equiv=”Content-Security-Policy” content=”default-src ‘self’; img-src https://*; child-src ‘none’;”>
Mitigating Cross-Site Scripting
CSP’s responsibility is to mitigate and report XSS attacks. These types of attacks will exploit the browser’s trust in the content received from the server. The target user’s browser will execute a malicious script because it trusts the content’s source regardless of where it’s coming from.
However, a CSP compatible browser will execute scripts loaded in source files from whitelisted domains and ignore all others. That way, it helps keep users safe from XSS attacks.
Using and Configuring CSP
Once you finish configuring CSP, it will add the Content-Security-Policy HTTP header to a web page. It will also provide you with the values needed to control what resources the user agent can use for that page.
Specifying the policy using the Content-Security-Policy HTTP header is pretty straightforward. Here are two examples of how you can do that.
The following policy will allow content from the sites same own origin, excluding the subdomains:
Content-Security-Policy: default-src ‘self’
The following policy will allow content from the specified domain (in this case, brid.tv) and all of its subdomains:
Content-Security-Policy: default-src ‘self’ *.brid.tv
These are just a few examples of how you can use CSP to define policies. There are many variations to these to allow/deny particular types of content from specific sources, so which ones you end up using will depend entirely on your needs.
Strict-Transport-Security
The HTTP Strict-Transport-Security is a response header that lets a website tell browsers that they should only access it using HTTPS.
Here’s one example how you can enable this that:
header(“Strict-Transport-Security: max-age=31536000; preload”);
Max-age — This metric represents the time (in seconds) that the browser should remember that a site should only be accessed using HTTPS.
Preload — See Preloading Strict Transport Security for details.
In everyday scenarios, if a website accepts a connection through HTTP and redirects users to HTTPS, they will still initially communicate with the non-secure version of the site before being redirected. That small time window of unsecured connection creates an opportunity for a man-in-the-middle attack.
The HTTP Strict Transport Security header exists to circumvent the above problem. It informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access it with HTTP to HTTPS requests.
How Browsers Handle This
When the users access your site for the first time using HTTPS, the website returns the Strict-Transport-Security header. After that, the users’ browser records this information so that next time they attempt to load a non-secure, HTTP version, the site will automatically load using HTTPS.
Once the max-age specified by this header expires, the next attempt to load the site via HTTP will proceed as a normal request. However, whenever the browser receives the Strict-Transport-Security header, this max-age time updates so that the site can refresh this timeout and prevent it from expiring.
Preloading Strict Transport Security
Another way to ensure that browsers never connect to your domain using an insecure connection is by submitting your domain to Google’s HSTS preload service. Although most widely-used browsers are already using this service, it is still not an officially recognized resource. Nevertheless, signing up for Google’s HSTS preload is a well-worthwhile addition to your app’s security and is worth considering.
Security Should Always Be Your Number-One Priority
Since data is so freely shared across the internet nowadays, web application security is of utmost importance. Implementing the above security methods will ensure that your application uses the most innovative technologies to safeguard your users’ data. If you handle your users’ personal information with great care, you will build consumer trust and grow your brand’s reputation faster. And if you ask us, these two factors are pivotal to your success in the online market nowadays, wouldn’t you agree?
