Intro about WordPress Firewalls

“Why do hackers hack websites?”, is one of the more philosophical questions of anyone with a website. Whatever the size of your WordPress site, protecting it from the common attacks against websites is definitely a concern.

Figuring out the best security option, (especially making the decision between a WordPress firewall and an antivirus) for your website requires a lot of research and technical know-how. But if you’ve decided on getting a WordPress firewall, NinjaFirewall is one of the options that you will have to consider.

This is why decided to test NinjaFirewall (v 3.2.4) for you, and to do it from a WordPress newbie’s point of view. We’ve pitted it against against the common exploits on WordPress sites to see if it stands our tests of fire.
A Web Application Firewall (or a WAF) provides customizable inspection and runs as an appliance, plugin, or a cloud-based service.


NinjaFirewall's logo
NinjaFirewall is a host-based WAF, that runs for WordPress.

Host-based firewalls on WordPress help protect against threats originating within the host (which, in this case, is your website). This means that they help reduce the risks of vulnerabilities in your website being exploited.

About NinjaFirewall

NinjaFirewall allows you to install and configure it just like a WordPress plugin, but it’s a ‘stand-alone’ plugin that intercepts all requests made to WordPress. The fact that it’s ‘stand-alone’ means it has its own settings, options, policies and rules that you can configure. If you’ve googled NinjaFirewall, you’d have seen phrases saying that the firewall ‘sits in front of WordPress’. This simply means that NinjaFirewall intercepts requests with the aim of alerting you of, and stopping any suspicious activity/requests before they affect your site.

NinjaFirewall is strict about how you install it, or make changes to its settings. It allows you to install ‘automatically’, via WordPress. Using manual (un)installation procedures, such as those using an FTP client (like FileZilla); or using the File Manager within cPanel will result in you getting locked out of the site.
This is a good thing since it only allows those with the admin access to make changes to it.
It is a great thing if you hate the manual installation process anyway.
It’s a horrible thing if you’ve got a rebellious streak.

Once you’ve installed the firewall, NinjaFirewall has an extensive list of configurable options, each of which controls how the firewall works. Most of these options are in the “Firewall Policies” section. None of these options are customizable though: the majority of them are Yes/No options, or have check-boxes.


NinjaFirewall's "Firewall Policies" are extensive, and will need novices to do their research.
NinjaFirewall’s extensive policies help protect your site.

An important point to note is that NinjaFirewall doesn’t allow you to write your own rules, since it only gives you predefined options. However, the firewall’s Anti-Malware feature allows you to add signatures for malware or suspicious activity (more on this later).

If you understand code, Ninjafirewall has extensive documentation that helps you with choosing the right options to set it up according to your site’s needs… But if you’re a novice, you’ll need some technical help, and time.

There are also a few hiccups that you might face during installation, that the NinjaFirewall team has documentation for. Again, great if you can read code.
Another point to note is that if you’ve got NinjaFirewall installed on another site with a custom configuration, the firewall allows you to import that configuration. This will override any firewall-related rule, option or configuration on the site you’re importing to. The only thing is that the versions of the firewall on both sites should match.

What NinjaFirewall Claims to Do for You

NinjaFirewall claims to intercept and determine which traffic to allow to your site, based on a whitelist and blacklist, as well as php.ini and .htaccess files. It also hooks (listens to for changes), scans, and intercepts all requests made to the PHP files on your site.
The firewall has a lot of features, all of which seem to add a lot of security functionalities to your site.


NinjaFirewall has a bunch of features that all look great, and they all show up as part of the plugin. Each feature has different options and settings too:

NinjaFirewall has a great-looking set of features
NinjaFirewall has a great-looking set of features

You don’t have a button to click on to activate the firewall: it activates as soon as it picks up that your WordPress site is loading. This is how it detects intrusions and affected files before they have a chance to infect your whole site.

We set the firewall to alert us of any activity it detected on our test site, using the Event Notifications feature.

This way, if the Firewall blocked any attacks, we’d check the Firewall log to see why/how it blocked the attack. If it didn’t, though, we looked through the following features of NinjaFirewall:

1. File Check

This feature helps create a ‘snapshot’ of files changed by comparing original files (or existing ones) against modifications. Once you create a snapshot (that you can later download or delete), it allows you to scan your site for file changes. You can not activate this scan before you create a snapshot.

2. Anti-Malware

The NinjaFirewall also has an Anti-Malware feature, that allows you to scan for hacks. According to NinjaFirewall’s documentation, this feature doesn’t alert you of spammy links, (like those that might redirect your visitors to porn sites).
However, it does alert you of malware that could damage your site, such as backdoors, based on signatures. This isn’t a great way to go about scanning sites though, especially since hacks are complex.
This is probably why this is the one feature on NinjaFirewall that allows you to add custom rules or signatures, for malware.

NinjaFirewall has an interesting feature called Anti-Malware, that allows you to add custom malware signatures.
NinjaFirewall has an interesting feature called Anti-Malware, that allows you to add custom malware signatures.

NinjaFirewall has handy documentation for how to go about this. You will need to understand what to create signatures for, in order to make use of this feature.
The Anti-Malware feature poses a couple of issue though. More on them here.

3. Firewall Log

It is what it sounds like: a log of everything NinjaFirewall found unusual, according to the rules you set in Firewall options. So if you’ve asked to be notified about any plugins updated, deleted or created, this log will contain all the details.

4. Live Log

This feature monitors HTTP and HTTPS traffic on your site, so it aims at protecting against any traffic related attacks (like Brute Force, DDoS, or weird IPs trying to access your site.)

What we tested it against

We ran a series of tests to evaluate first-hand, the efficiency of NinjaFirewall, against some of the common attacks WordPress sites face. For this, we created a test-site (which would be the stand-in for your website):

The vulnerabilities we tested the firewall against were:

1. SQL Injection

The Firestorm real-estate plugin (actually v 2.03), is one that contained a vulnerability that allowed for SQL Injection. This plugin allows you to add real estate listings to your WordPress site.

Testing NinjaFirewall against SQL Injection

To exploit this vulnerability, we tried accessing entering SQL code into the Firestorm plugin to get data from wp_users. (For those of us who don’t know what wp_user actually does, it allows you to get data from, and modify both the roles and capabilities of WordPress users other than the admin.)

Here is the SQL code we used: UNION SELECT 1, user_pass, 3, 4, 5, 6, 7, 8 from wp_users.

Because this version of the plugin in vulnerable, it will execute the code to try and select the user credentials from users 3, 4, 5, 6 and 7.

We used this in our browser’s address bar.

(Note: This is why for this attack and the couple others following, we’re going to ask you to look closely at the address bar.)

Running the test in the address bar

Once we entered the same code into the address bar of the browser, this is what showed up on the test site (look at the address bar carefully, please):

NinjaFirewall doesn't take entering SQL code into the address bar very lightly.
NinjaFirewall doesn’t take entering SQL code into the address bar very lightly.


But how did things work out behind the scenes of the attack?

Firewall Log for SQL Injection

This is what NinjaFirewall’s Firewall Log had to show us-

NinjaFirewall's Firewall Log registered an attack
NinjaFirewall’s Firewall Log registered an attack

Looks like the firewall had this exploit already in its list in the Rules Editor section, and hence it detected the exploit and prevented it from occurring too.

2. Arbitrary File Upload and Local File Inclusion (LFI)

There were a couple of vulnerable plugins that came to mind when we thought of Local File Inclusion. One was Slider Revolution (v 3.05), and the other was Gravity Forms (< v 1.8.19).

We chose Slider Revolution though, because it allowed to make both exploits, and because more than 100,000 sites were attacked in 2014 through this plugin.

Testing NinjaFirewall against Local File Inclusion

The Slider Revolution plugin was used to perform Local File Inclusion on vulnerable websites in the following manner:

Say the vulnerable site was called ‘’.

The vulnerability allowed attackers to request the RevSlider plugin on the vulnerable site to show the images in the slider. Once it did that, the attackers would also try to figure out the structure of the WordPress directory. They would then get it to include files on the website’s local server (like the wp_config files) to the files it revealed. So the final URL entered on the site would be something like:

We used a very similar approach to try and get the plugin to include the wp_config files of the website, and to reveal them.

Here is how NinjaFirewall reacted:

Running the test

NinjaFirewall on Local File Inclusion: You shall not pass!
NinjaFirewall didn’t let us perform a Local File Inclusion.


Since the action got blocked, we just checked out the Firewall Log.

Firewall Log for Local File Inclusion

What NinjaFirewall's Firewall Log registered the LFI attack as
This is what NinjaFirewall had to say about the attempt to include a file locally to the test-site.

Testing NinjaFirewall against Arbitrary File Upload

Again, trying to get to two attacks with the same plugin, we tried uploading random (or arbitrary) files to the test site. If the attempt is successful, the damage to the site would depend on the kind of file uploaded, and what it was intended to do.

Take a look at the address bar to see what we’ve tried to do.

Now don’t get confused… We named the files to be uploaded as “revslider” so that it would be accepted more easily by the plugin.

Running the test

NinjaFirewall successfully blocks Arbitrary File Uploads.
We used Google Chrome’s extension to test the Arbitrary File Upload exploit. The exploit was unsuccessful

Again, we only checked out the Firewall Log, since this attack was unsuccessful.

Firewall Log for Arbitrary File Upload

Here is what the Firewall Log said:

The Firewall Log for Arbitrary File Uploads
The Firewall Log for Arbitrary File Uploads

3. Remote File Inclusion (RFI), Arbitrary Code Execution, and Backdoors (a custom hack)

We used TimThumb because it was a plugin that was widely used, and exhibited a vulnerability that allowed for millions of WordPress sites to get hacked. This test was therefore meant to check the basics of the firewall.

Testing NinjaFirewall against Remote File Inclusion and Arbitrary Code Execution

For this, we used the (currently defunct) Pict.Mobi widget, that used TimThumb (v 1.28) on the test site. Obviously since the RFI exploit would need a hackfile to be included from a remote location, we also created another site that would host the bad file.
We took the approach a hacker would: we first confirmed that the (test) site used TimThumb, and that it used a vulnerable version.

"Does this site have TimThumb?"- An optimistic hacker
Most hackers looks for vulnerable plugins on your site.


Then selected a very small file (in this case, it was a 16X16 .png icon), and modified it to contain PHP code.

Modifying a small image to contain malicious PHP code
Modifying a small image to contain malicious PHP code


Next we used the TimThumb vulnerability to include the file remotely to the test site. Note that the file was PHP, which means that any time it was accessed, it would run.

Including the malicious file remotely to our website
Including the malicious file remotely to our website (notice the address bar!)


Sure, it was an image file, so it could easily bypass the site’s usual sensors, but the PHP code could still be accessed, and executed.

Testing NinjaFirewall against Backdoors

We wanted to kill three birds with one stone, so we made sure to create an encrypted shell for the PHP code on the image before we uploaded it.

Running the test

We then extracted the code from the hackfile shell, just like a hacker would:

Extracting code from the hackfile's shell
Extracting code from the hackfile’s shell

And then ran it.

Executing the code. A three-in-one attack.The website gave us what we wanted.
Executing the code. A three-in-one attack. The website gave us what we wanted.

NinjaFirewall didn’t stop the attack.

We think it was because NinjaFirewall has a list of rules for what attacks should look like, in a section called Rules Editor.

A look at NinjaFirewall's Rules Editor
A look at NinjaFirewall’s Rules Editor

Click on the drop-down, and you see the list of rules that NinjaFirewalls follows:

The Rules Editor has an extensive list
The Rules Editor has an extensive list

These rules are internal to NinjaFirewall, so you can’t see what exactly each rule entails.

The attack we performed though, didn’t exactly go by the rules of how the attacks worked.
The results of the tests are as follows:

Firewall Log

The log didn’t pick up on the hack. In fact, it only listed the backdoor we’d tested it for.

The Firewall Log only registered the backdoor.
The Firewall Log only registered the backdoor.

File Check

The firewall didn’t detect changes in files. We were still able to list the files in the WordPress directory.

The firewall didn’t detect changes in files. We were still able to list the files in the NinjaFirewall's File Check resultsdirectory.
What NinjaFirewall’s File Check showed up


We didn’t expect this feature to remove the malware, because it’s only a scanner.

Unfortunately, it didn’t find the infected files. We were under attack, and this is what the anti-malware feature said:

What the Anti-Malware feature said
What the Anti-Malware feature said

Live Log

No blips on this feature either.

The results on Live Log
The results on Live Log

Unresolved issues with NinjaFirewall

Since this is a review of the entirety of NinjaFirewall, we didn’t only test it against vulnerabilities. We also checked for issues other than those of protection. Most of these issues are documented on NinjaFirewall’s forum on WordPress, or on its online documentation.

● Anti-Malware scans time out

The Anti-Malware feature on NinjaFirewall allows you to scan files in a particular directory for your site for malware (by default this is/var/www/html/wordpress/).

The thing is, by default, this feature scans your site for malware in files that have been created or changed in the last 7 days. You can change the time period (or Timestamp) or even make it zero, in which case it scans your whole site.

The options that Anti-Malware shows you
The options that Anti-Malware shows you

However, when if your website is on a shared host, there is one major problem you could face: the Anti-Malware scan timing out.
The feature stops scanning your site after a certain time period that is set by your web host. This means that if you have too many files on your site, the scan will get cut short. Your site could never get fully scanned, unless you try some workarounds, (like this one suggested by the NinjaFirewall team). This is probably why NinjaFirewall’s Anti-Malware feature also has the two options of “Ignore file extensions” and “Ignore files/folders”:

Working around NinjaFirewall's time-out issue
Working around NinjaFirewall’s time-out issue

While there isn’t anything NinjaFirewall can do to change the timing out of the scan, it is a huge drawback for users who want to scan their sites.

● The Anti-Malware feature uses only signatures to detect malware

This is a widely-used method to identify malware and viruses, but it doesn’t catch everything. This is why most security scanners use it in combination with other approaches. Hacks utilize vulnerabilities on your site, but how bad code is run on your site depends completely on how hackers want to carry out the attack. So the ‘signature’ of malware could always be altered in small ways so as to escape detection. This is why, as we explained earlier, our exploit of the vulnerabilities in the Pict.Mobi plugin allowed for RFI, Arbitrary Code Execution and Backdoors on our test site.

● The firewall modifies .htaccess files

NinjaFirewall backs up the PHP INI and .htaccess files that it has to modify, but modifying the .htaccess file in itself can wreak a lot of havoc on your site. The .htaccess file controls a lot on your WordPress site. One of its more obvious functions is access control (i.e. which users are allowed to your website), but it also dictates how files with certain extensions run on your site. This is why any minor slip-up with this file could cause your server to majorly malfunction. Just to be on the safer side, we recommend that you perform a backup of your entire site rather than just the .htaccess file. That way even if something breaks, you can always roll back to a working version of your site.

● Modifying the .htaccess files and php.ini files slows down your site

.htaccess allows you access to the configuration of directories on your website even if you don’t have your hosting server’s (eg: Apache) main configuration file.

This means, when your site is configured to direct traffic based on the modification made to .htaccess, Apache has to look for, and load all the .htaccess files on any request made to your site. As a result, your WordPress site’s load time increases.

It’s a good way to direct traffic when your main server configuration file isn’t accessible, but otherwise it isn’t a great thing.

● The firewall interrupts backup operations regularly

NinjaFirewall triggers false alarms when WordPress backup plugins are run, sometimes doesn’t allow backup plugins to backup the site. The firewall also has to be disabled before migrating your site to a new IP address.

● Can’t manually install NinjaFirewall

As mentioned earlier, NinjaFirewall might log you out of your WordPress site and deny you access if you use an FTP client to make changes to it, or even uninstall it. Anything that you need to do with respect with this plugin has to be done from your WordPress dashboard.


The NinjaFirewall seems like a powerful tool against known attacks that occur according to their signatures. But the thing is that most hackers know these signatures, and know that most security measures protect against these signatures. So they modify the signatures to perform more successful, and at times, most devastating attacks.

Alerting of attacks after they’ve taken place isn’t something a lot of website owners can afford, especially with the damage hacks can wreck.
Did you like this review of NinjaFirewall? Would you like to see other firewalls tested too? Let us know in the comments!

Why do you need it?

Can your business continue to function if you were to lose your data? If your answer is a clear no, then having a disaster recovery plan is a must for you. At some point down the road, your data is going to be in danger. It could be a machine error. It could be a simple human error. It could be a tornado the size of Nebraska. But sooner or later, you’re going to be in a situation where you’re at risk of losing some or all of your data. Some of the common consequences of a disaster –

  • Loss of business/customers
  • Loss of credibility/goodwill
  • Cash flow problems
  • Loss of operational data
  • Financial loss

90% of businesses that lose data from a disaster are forced to shut down within 2 years of the disaster. 50% of businesses experiencing a computer outage will be forced to shut within 5 years. (Source: London Chamber of Commerce). So, having a disaster recovery plan is the best insurance for your business and entire data. But what are the possible reasons behind this ‘disaster’? And how do you deal with them?

It's wise to have a recovery plan for your website
It’s wise to have a recovery plan for your WordPress site

What Can Go Wrong?

Hardware Failure

While we’ve made huge strides in terms of technology, it’s still not perfect. There are bound to beissues now and then. Hard disks, which are the most popular form of storage media, fail more often than you think. The statistical figure indicated is by no means trivial. Other forms of hardware failure can have a similar impact on your business.

Web-hosting Failure

As every site is hosted using one of the providers, a failure on their end undoubtedly spells disaster. Any sort of networking problem can bring down your site. However, this doesn’t pose a big threat to your data. But that’s not the end of it. These hosting providers are a common target of hackers. Once the server is compromised, the hackers have access to all the data that resides on it. The hackers can thus attack 1000s of site by hacking a single provider. Sometimes, hosting providers even suspend your account without prior notice.

Natural Calamities

Natural calamities, though rare, can pose a huge threat to your data. Hurricane Sandy, which hit New York City in 2012, had companies fighting hard to keep their data centers up. It was one of the busiest days for many of them.

WordPress Issues

WordPress, though WP core is known to be stable, has its own share of problems that crop up from time to time. The most common issue that users face is that of version incompatibility. Though WordPress versions are meant to be backward compatible, quite often, a WordPress update ends up breaking a plugin or theme due to incompatibility. Underlying API changes in a new version could also result in breaking parts of your site.

Plugin/ Theme Issues

WordPress is an open platform, inviting a lot of people to develop plugins and themes. Since each plugin and theme is written independently, not all of them follow the same set of coding guidelines and standards. This makes installing new themes and plugins on your site a risky proposition. A new addition may be incompatible with the underlying WordPress version. Some of the changes made by plugins and themes are –

  • Bad database changes
  • Addition of new tables
  • Modification of standard WordPress tables
  • Changing WordPress configuration files
  • Introducing incompatible code
  • Corruption of .htaccess files

This can result in breaking parts of your site or worse, lead to a crash. Upgrading plugins and themes can also lead to similar issues.

Hacks and Vulnerabilities

WordPress core, by itself, is known to be safe and stable. However, plugins and themes added by developers hailing from diverse backgrounds have become game changers when it comes to WordPress security. Plugins and themes together make up the biggest source of  vulnerabilities found in recent times. Popular plugins like MailPoet, W3Total Cache and Super Cache have been exploited to attack thousands of sites. Similarly, themes are also vulnerable to attacks. The TimThumb library included in many themes was exploited to compromise tons of sites.

Hackers are always looking for new ways to launch attacks on WordPress sites. While most hackers look to make quick profits, some do it merely for fun. They can install malware that’s extremely hard to detect and get rid of. They can also wipe out all of your site’s data.

Human Errors

To err is human. But these errors can prove to be very costly. You can delete a single post or the entire database. Ben Congleton of Olark describes in an interview, a case where a human error nearly took down his business.

The reason behind the disaster can vary, but they will all impact you in the same way. They can all potentially take down your site, and thus your business. So what is the best possible plan to recover from a disaster?

Putting Together a Disaster Recovery Plan

Backup, Backup, Backup: the Cornerstone of a Disaster Recovery Plan

Not enough emphasis can be laid on the importance of backups. Taking regular backups of your data is critical for any business. That way if anything untoward happens, you can recover your site in a matter of few minutes. There are multiple options available from which you can choose. However, it is best to opt for a managed offsite backup service like BlogVault that can handle any situation with ease.

Plan for Extended Downtime

Your plan should cover what you will do if the downtime from the disaster is expected to last more than a few days. For instance, there may be a major outage with your hosting provider. You’ll need to identify possible alternatives to host your site.

Emergency Contact

A natural disaster or emergency could cut off all your regular avenues of communication, so adding a communications element to your plan is important as well. Notifying your customers about the downtime is extremely important. However, when you lose data, your customer information is lost too. Hence it is critical that you have a separate emergency contact list, such as all customer email IDs, stored separately in an easily accessible place.

Test the Plan

Do a test run of your disaster recovery plan to make sure that it works when needed. Also ensure that your plan is known to multiple people at your company so that they can spring into action immediately when disaster strikes.

Disasters do happen, and your company’s data is one of its most important assets. When disaster strikes, you need to be sure that you can get your data back quickly, so there is minimal impact to your business. So work on that disaster recovery plan today, in case you already haven’t. Better safe than sorry, right?

The correct answer to this question, for any WordPress agency, is that, it depends. Running an agency which delivers quality products and services can be daunting.  While many are looking for the answers to be able to balance both, very few agencies actually can manage both successfully.

A good example in the Indian WordPress community is rtCamp. Asia’s first VIP partner agency has two popular products: EasyEngine and rtMedia. It is interesting to note that, both these products were born out of requirements the company had at those respective times. The statement by Rahul Bansal, “You should only develop on platform which you use,” rings true here it seems.

rtMedia was born when Bansal, suggested that his college use BuddyPress to build their own social network. His professors pointed out that a popular social network at the time- like Orkut, had images and videos and without that students might be bored. BuddyPress didn’t have the option to add media at the time and rtMedia was born to solve that problem. While the plugin was released 2 months after rtCamp was formalized, the product was being worked on before the birth of rtCamp itself, Bansal recollects.

In the case of EasyEngine, Bansal used NGNIX to reduce the budget for hosting his blog network which at that time used to get half a million page views. He found the solution to be efficient. However, being the only one in the company at the time to offer this solution, he refrained from making it their USP.

Over time, requests from Bansal’s friends in the blogging community resulted in moving their sites, over NGNIX, one by one. To avoid repeating the same task EasyEngine was created.

The success of both these products, coupled with the recent success of rtCamp as a VIP partner agency may paint a rosy picture of a company balancing both service and products. However, Bansal, would be the first to dispel you of such a notion.

There cannot be greater proof of the difficulty in delivering quality on both fronts; products and services, than when Bansal says that if he could travel in time, then he would kill either products or services on day one of rtCamp.

His reasoning is simple: unless a company has a manager dedicated to ideation, and development of the product, life can get very tough. As Bansal states that being the only person to head both products and services means that person may end up becoming a bottleneck in their own company; as all the approvals have to go through one person.

It may not be a satisfying answer but smaller or younger companies will do well to take note of the experiences of Asia’s premier WordPress company. Running a WordPress agency can be stressful at most times. Learning from each other’s experiences extends the feeling of community which is so inherent to WordPress, while helping us make smart choices too.

Let us get the common question about Asia’s first VIP agency out of the way. What does rtCamp stand for?

RT, as the founder Rahul Bansal himself explained to us, stands for ‘Round Table’ after King Arthur’s famed table in the Arthurian Legend. Camp, refers to the whole circuit of bar/blog/php camps in which, Bansal, as a successful WordPress freelancer, actively participated.

Two factors influenced the name and the culture at rtCamp. One factor Bansal says was his “hunger for equality”- the desire that everyone must have a say and contribute by taking initiative instead of just taking orders. The other factor was the unencumbered, open-source loving, community-driven culture around WordPress; which was represented by bar camps and so on, which he had come to appreciate.

These values he says got reflected in their work culture and while he adds that such core values cannot be altered according to the balance sheet, he can also trace the foundation of rtCamp’s growth to these values.

At rtCamp, their core values, have resulted in them building an agency where they love open-source, contribute back to the WordPress community, share the spotlight, and celebrate the contributions as well as exits of their team members.

A reflection of this is Bansal’s description of how, the now VIP partner WordPress agency, landed their first big client; when they were much smaller and younger.

Bansal is quick to attribute credit to the then Marketing Head, Gajanan Sapate; who is no longer with rtCamp and has started his own social media agency, SocialChamps. Sapate had approached Bansal with the idea of creating a company profile on LinkedIn- a popular professional social networking platform. Bansal, admittedly, was not too keen on the idea. Sapate made the choice to create the company profile on LinkedIn without his approval Bansal recollects, appreciatively.

When the ‘big client’- Geometric, went searching on LinkedIn, rtCamp had an advantage, as they were probably the only company to be listed as a WordPress agency in India at the time; around 2012.

This is only one example of how Bansal, and rtCamp set up a platform for many to take initiative and grow. Many of them have left the agency to carry on to big projects while continuing to make contributions to the WordPress community.

If you need an example of the extent to which rtCamp’s contributions to WP core has had an impact, you only need to look at the citation they received when becoming VIP partners. It was consistent contributions to WordPress Core which was mentioned as the main reason for being chosen as Asia’s first VIP partner agency.

Another aspect of the agency that Rahul takes pride in, is the  involvement of rtCampers in the WordPress community itself- participation in WordCamps and publishing of tutorials. He says that the company encourages team members to make such contributions.

The culture of sharing the spotlight and getting better at one’s job, while contributing back to the community in combination have produced a team which today boasts of only enterprise clients or funded clients. While rtCamp was not born as an enterprise level WordPress agency, the core values as described by Bansal certainly seem to reflect in the work and now in the client base the agency has developed over the years.

It is no mean feat for a WordPress agency in India to have become Asia’s first VIP partner. The partnership means that they are in contention to land some of the biggest projects in the world. Today, as Rahul Bansal, the founder of rtCamp states that, their client list contains only ‘big clients’- enterprise level or companies which are funded.

Many young WordPress agencies might be wondering what is the roadmap to achieving such a feat? No company starts out big though. Just like every other venture, rtCamp’s story too has an arc to it.

They landed their first enterprise level client, Geometric, much before they were aiming for it, or much before they were ready for it. At a time when they were very much the size of a young startup. However, their success today must mean that they did some things right along the way.

Here are some takeaways for WordPress agencies just starting out.


A WordPress Agency by any other name?

Absolutely not! Here’s why

The beginning is always about being in the right place at the right time. rtCamp created a company profile on LinkedIn. On the profile they identified themselves as a WordPress agency. This was the first point of contact between Geometric and rtCamp; and as it turned out a crucial one.

As Serendipitous as this find may seem, it was anything but that. Planning is key to earning any stroke of luck. When the Marketing Head of rtCamp at the time, Gajanan Sapate had suggested building a presence on LinkedIn, Bansal was not keen. The profile though, was created without Bansal’s approval and it proved to be a vital move.

Geometric had decided to use WordPress to build their site. When they were looking for a WordPress agency on LinkedIn, then they found rtCamp. Bansal suspects that the company’s search on LinkedIn for a WordPress agency yielded rtCamp as the only  result.

The conviction to clearly state their specialization meant that the agency could not go after projects based on other platforms. It also meant that it set them apart and established their expertise; this worked in their favour.


With Big Clients come Big Challenges for small WordPress Agencies

The beginning is just that. With enterprise level clients, come many demands. As Bansal himself admitted, the combined value of all their clients at the time was much less than that that of Geometric.

He recalls how they were required to fulfil many procedures and adapt to a long sales cycle. In this case, it was around 6 months. In the case of enterprise level clients this is not unusual; with a sales cycle lasting anywhere between 3-6 months. However, for a company which had only experienced maximum sales cycles of 2 weeks, 6 months seemed like a long, long time.

Not only did the entire process take more time than what they were used to, all the steps were new too. For example, Bansal admits that they were new to the idea of purchase orders. Apart from these challenges, they also failed many of the checks; like not having access control (such as  magnetic stripe cards and so on), which did not help either.

It was clear to Geometric that rtCamp was not familiar with enterprise level processes and practices. All these points raise the question- “how did rtCamp eventually land the project?” and “Why did both rtCamp and Geometric stick with each other?”


Honest is the Best Policy

Bansal mentions instances during his freelancing days as a web developer when he readily admitted to clients that he offered WordPress as platform because he did not work any other CMS.

This policy about being upfront with the clients extends to rtCamp too. Having displayed their prowess with WordPress(more on this below), he remembers not hiding from the clients rtCamp’s need to learn about about dealing with enterprise level clients. Both these factors allowed Geometric to make a fair assessment and help rtCamp catch up with the business processes side of the deal, as a slightly amused Bansal now recalls.


Contribute Back To The Community

Bansal points to a combination of factors which contributed to their success. The combination of factors being, his famous blog, an extensive WP portfolio, open source projects like rtMedia, and knowledge of content, and analytics.

Among all of these factors, Bansal recognises the role his blog and rtCamp’s community contributions played, in making people aware of his agency. They also, according to Bansal, were the reasons the client was convinced regarding his agency’s prowess on WordPress. This is why he highly recommends, for those involved in open-source communities to contribute to the community.

Bansal states that these factors combined with a willingness to learn and grow along with the demands of project, has now led to a fruitful relationship with Geometric


Improve Before the Need Arises

Apart from all of these factors a willingness to deliver better quality now, rather than waiting for later, seems to have paid off in the case of rtCamp. A couple of years on after Geometric, rtCamp shifted its focus entirely to preparing for big clients  and becoming VIP partners.

Part of the road map to achieve their ambition of becoming VIP partners, was to deliver code which adhered to VIP standards. Implementing such quality standards when the clients were not asking for it was important. When rtCamp finally got their first enterprise client, which was to be verified by Automattic, it was approved in the first round itself recollects Bansal.

The success story of rtCamp is a good example of how positioning yourself in the right manner, willingness to learn on the go, participating in the community, and playing the game with foresight pays off.

Rahul Bansal, the founder of rtCamp; Asia’s first VIP partner agency, began his career as a freelance WordPress (WP) developer. The success of the company today can be traced back to ideas that were born during those days.

Being a freelance, WordPress developer in 2007-08 India is an interesting story for many reasons. Among the lot, the reason why it stands out the most is the choice of platform itself- WordPress. The platform was barely popular in the country at the time.

Asking him about the beginning of the journey and his success as a freelancer will quickly assure you that doing what you enjoy, taking up challenges and learning as you go, will take you a long way.

Right from starting a blog (after watching friend do the same), to taking up freelance projects based on WordPress for the sake of learning more on the platform; which he not only enjoyed using and but also afforded him the freedom to express himself, Rahul Bansal’s choices reflect that enjoying your work and sustaining a hunger for learning can lead to good things for WordPress freelancers.


Enjoy What You Do: Blogging, as the beginning of WordPress Development

The beginning was fairly innocuous. Bansal started a blog in his final year of undergrad. The idea itself emerged as a result of following the work of a friend; who he often copied. Regardless, he began to enjoy the blogging experience. The blog had thousands of subscribers and used to garner half a million page views at it peak. Safe to say Bansal was running a successful blog.

You might wonder- Why start off with the blog, when we are telling you the success story of a freelance WordPress developer?

The reason lies in an anecdote that Bansal recollects. Once, he bid on a project, and to his surprise the client awarded him the project before the details were finalized. Upon inquiring he learnt the client’s reasoning. If Bansal was running  such a successful blog, then he must be doing something right.


Showcase Your Work

This might be a good lesson for young WordPress freelancers, or freelancers in all fields. Create a platform to display your skills and work, and the right projects may just find you. As Bansal himself says, “It’s not your academics, [but] it’s your skills [which count] on the Internet.” The blog, which made this possible was Devil’s Workshop. Although it is no longer updated, you can still find the published works posted there.

During this period he chanced upon an opportunity to monetise the blog. This opportunity came in the form of Google AdSense. Having installed it out of curiosity, Bansal realised by the last year of post-graduation that the platform was earning him enough revenue to consider taking up blogging professionally.

However, the task of convincing parents and family members that this was a viable career choice remained.

Bansal drafted an answer for the impending questions, which was simple and for that reason brilliant- His solution was to draw an analogy between his profession and news agencies. While newspapers are distributed to the public at subsidised rates, the revenue is earned through ads. Much the same way, he explained that his blog was like an online newspaper earning revenues from ads. As convincing an answer as this might seem to us, Bansal himself believes that the point which convinced his parents was that he was earning enough from his blog to not take any money from them right from the final year of his M.Tech.

Enjoying the blogging experience led him to a revenue stream through AdSense. The desire to take it up professionally and have more control over the blog and content led him to WordPress.


Learn While You Earn

He had begun to customise his blog and found the coding experience on WordPress easy and enjoyable. Finding work enjoyable was again sufficient for the professional blogger to add freelance WordPress developer to his CV.

Not happy with tinkering with the CMS and learning about it on his own time and money, Bansal came up with an unique approach to help him learn and earn at the same time. He listed all the things which he wanted to learn on WordPress and signed up on sites for freelancers; like

He says that he chose projects with realistic deadlines and possibilities which required him to learn and work on the list of things he wanted to know on WordPress. This approach ensured that he continued to grow more knowledgeable about the platform which he had grown to appreciate more and more. Besides the extra money didn’t hurt.

A key thing to note here is that the love for the platform led him to the job. Bansal mentions that he was already earning money from ads on his blog. “It was due WordPress that I became a web developer, not the other way around,” he says.


Upfront About the Uptake: Why WordPress

If you ask Bansal why WordPress was his focus in 2008-2009 when the platform had not yet even reared its head in India, like always he has simple and convincing answer. He says that you should develop on a platform which you use. Since WordPress worked for him he worked on solely on this open-source CMS. He was always upfront to the clients about his reasons and motives.

The tactic seems to have paid off. This ensured that most of his clients returned to him. So much so that the workload was starting to expand beyond the capacity of an individual and shortly after his M.Tech, in  few months, he would register rtCamp. He didn’t know then but the agency would go on to become Asia’s first and so far only VIP partner agency.

However, Rahul Bansal’s choices and practices, seem to indicate that the seeds for rtCamp’s success were already sown during his freelancing days. The success story, is a tale of being guided by one’s interests, making good; but difficult, choices, and finally making the more difficult choice of sticking by one’s decisions. Freelance WordPress developers and agencies across the country would find good clues to planning their way forward from these ideas.

BlogVault has developed, and in collaboration with Pantheon created Pantheon Migrations. Pantheon is the world’s largest website management platform, delivering Drupal and WordPress as a service. Pantheon’s multi-tenant, container-based cloud platform enables web teams to build, launch, and run all of their websites from a single dashboard with ease. 

You can now migrate your WordPress sites to Pantheon with ease. Just input your SFTP credentials, email, and the destination URL, and you’re good to go. Pantheon will notify you when the migration begins and completes via email. You can also track the progress of the entire process on our website, via your BlogVault dashboard.

For us, at BlogVault this is the latest partnership for migrations. Previously we have partnered with other companies like WP Engine, Savii, & Cloudways. Now you can enjoy the convenience and expertise we strive to bring you while migrating to Pantheon as well.

easy WordPress migrations
BlogVault partners with Pantheon for easy WordPress migrations

You can always enjoy easy migrations with our backup plugin, BlogVault too. Apart from backup, and migrations, the plugin also offers, auto-restore, test-restore and security settings to improve your WordPress website security posture.

While the partnership adds an exciting page to BlogVault’s story, we’re also looking ahead. Our mission of developing the best in WordPress backup and security has led us to our next product. It’ll launch shortly and promises to change the way users deal with WordPress security issues on their sites. Until then, stay safe and don’t forget to backup!

Watching dominoes fall is always fun. And why wouldn’t it be? It’s a harmless, yet mesmerizing display of organized chaos. But if it did represent something harmful, there would be much reason to worry. Cross-site scripting attacks, at their worst, are the dominoes of common website vulnerabilities.

Cross-Site Scripting is a website attack that can be compared to dominoes falling, because of the damage it causes.
Once dominoes start falling, there’s no stopping them.

Cross-site scripting, generally known as XSS, is a type of Injection attack. It works a little differently from most other attacks, because it in addition to exploiting WordPress websites and their servers, the attack also utilizes web browsers. How it works in general Cross-Site Scripting starts out the way most injection attacks (such as SQL Injection) do: by accepting user inputs. An attacker injects malicious scripts into good WordPress sites through a part of the website that accepts users’ inputs (like a comment field). So if an attacker could use, say malicious JavaScript code within “<script>… </script>” tags in the comment section, the code would run on the browser. This would allow the attacker access to any information they can glean from the visitor’s browser, from cookies to saved or entered login credentials. How to prevent Cross-Site Scripting Making sure that your: Your web browser makes use of the same origin policy- Web browsers usually have a set of rules, by which one web page is allowed to access script on another only if they had the same origin. If a browser doesn’t check the origin of the script of web pages, it results in a vulnerability that can be used by attackers to inject malicious scripts.  This means that users’ browsers would execute the code. All of this is moot though, if one of your website’s visitors uses a browser that doesn’t have this policy… in which case stricter security measures on your site would help. Website can tell the difference between markup tags and actual content on a page– Websites are vulnerable to XSS attacks when they can’t make out the difference between markup code and content that has to load on its pages. This means that if there were a piece of text, like an equation having the ‘<’ sign, and executable code (containing the <script> tag, the browser would mess them both up. This could be because the developers forgot to implement rules that dictated that “<” signs in text on the web page would be represented as “&lt;”. When this happens, the website is vulnerable. Website has input validation and sanitization- None of this would happen if the standards of accepting users’ inputs was very high. Categories of XSS attacks Cross-Site Scripting is a very complex attack especially because of how it can be categorized. It can be put in buckets, based on the following criteria:

  1. Whether the malicious script (from users’ inputs) is stored-
    1. If the malicious script is stored on the website or browser’s database, the attack is categorised as a Stored (or Persistent) XSS attack.
    2. If it’s reflected to other visitors instead, it’s called a Reflected XSS (or Non-persistent) attack.
    3. There is also another kind of XSS attacks, called the DOM (Document Object Model)-based XSS attack that we’ll explain later some time.
  2. Which side accepts unvalidated user-inputs (this categorization overlaps the Stored and Reflected categorisation)-
    1. Server-side XSS attacks
    2. Client-side XSS attacks

Stored (or persistent) XSS Attack Stored XSS usually occurs when user inputs are taken and stored on a database. In this case, the user is affected because unsafe data is run on the browser. Any attacker could input malicious code on a vulnerable website just once, and it would get stored (persistently) on the server. When any other user accesses the website, they would get affected. The malicious code infects the user’s browser, and retrieves sensitive data, (such as usernames and passwords) for any site the user might use the browser to visit. Here is what a Stored (or Persistent) XSS attack looks like:

Stored XSS attacks can cause a lot of damage. This image shows how one works, in general.
Stored XSS attacks can cause a lot of damage. This image shows how one works, in general.

One of the most well-known, real-world examples of this attack, is that of the MySpace worm of 2005. The worm was scripted in JavaScript to be self-propagating. So instead of just affecting people who visited the point of origin of the worm, it affected visitors of the original victims, thus propagating exponentially. Here’s how it loosely worked:

Samy Kamkar hacked MySpace in 2005, and introduced an XSS worm that took over 1 million profiles in 6 hours. It was an example of the scope of a Stored XSS attack.
Samy Kamkar hacked MySpace in 2005, and introduced an XSS worm that took over 1 million profiles in 6 hours.

This attack is precisely why we compared XSS attacks to dominoes falling.   Reflected (or non-persistent) XSS attack Reflected XSS attacks are a different thing altogether. They are the most well-known sort of XSS, and can pose a serious threat, if not prepared for. Here’s a general example, to explain how this attack could work:

Reflected XSS is the more well-known sort of XSS attack.
Reflected XSS is the more well-known sort of XSS attack.

This attack could be used to do anything from launching a DDoS attack (as seen in the above example), to scanning the websites/ profiles/ browsers of every visitor to your website, for vulnerabilities that could later be exploited.

Cross-Site Scripting could use information from any website/web service you use.
Cross-Site Scripting could use information from any website/web service you use.

The Cross-site Scripting attack is one that has existed for a long time. Unfortunately, until the MySpace worm was created, not many in the realm of internet security took it very seriously. However, according to a report by WhiteHat Security in 2015, even 10 years after the MySpace worm, 47% of all websites are still vulnerable to this kind of attack. This attack relies on user inputs not being validated or sanitised before being processed. So the best way to protect your WordPress website, is to make sure that it doesn’t take your subscribers’ inputs lightly. This obviously means you should make sure that the plugins and themes on your site accepting user inputs validate them first. But even otherwise, choosing an extra security feature can never cause harm. If you’d like to try out a website scanner that is 100% accurate, requires no technical assistance, and also helps you remove hacks, visit MalCare.

Removing malware from your website, and getting rid of hacks is a painstaking process. When you’re a website owner whose site has been hacked, your online reputation takes a hit. It’s only more distressing when you keep getting hacked. The reason behind this, most of the time, is a ‘backdoor’.

Having a backdoor could be explained with some ease, by comparing it to something we could call a “spare-key situation”.

Suppose you had a spare key to your house, but you dropped it somewhere on your street. Someone creepy has found it, and unfortunately for you, this person also knows exactly where you live. Of course you don’t know about it, but you notice changes at home.

Whether all the furniture in your house is gone, or whether the sofa is always a little warmer in the morning depends entirely on what this person with the spare key is doing in your house. This means unless you change your locks or employ other security measures, this stranger has full access to your home, and will keep coming back.

Hackers also do something similar when they hack WordPress sites.

When a hacker exploits a vulnerability and hacks a site, they want to be able to enter it again in the future. They also want to do so, without needing to put in the effort again. This becomes difficult though, if the site owner closes the vulnerability by updating the exploitable theme/plugin. That is why hackers leave behind code called backdoors on the site. This way, even if the vulnerability is fixed, the backdoor remains. Backdoors are inconspicuous, because the longer they stay hidden, the longer the attacker has a way to get back in.
Backdoors can give hackers complete control through Arbitrary Code Execution. One of the most common backdoors is ‘Filesman’. Since it’s feature-rich, it allows hackers to perform a variety of functions. However, there are others too, which might be just three-four words of code, but prove to be equally dangerous.

A lot of the time, backdoors are disguised as WordPress files, and are hidden by the hacker in a place only they know. You, as an admin, could find the file only if you combed through all the WordPress files. This is especially difficult because backdoors can go in so many different places.

Here are a few places backdoors are usually hidden on your WordPress site:

  1. In core WordPress folders: Adding a new file to, or modifying an existing file in a core WordPress folder (e.g. wp-includes or wp-admin or wp-content) can easily go unnoticed. Especially in the wp-includes folder, since it contains every file ever included to the site. This is why we noticed a lot of backdoors here.
  2. In new, innocent-looking folders: Hackers could add hackfiles to new files that look completely innocuous, like ./images/
  3. Plugins and Themes: Not many people bother to check these folders after the plugins/themes have been installed. This makes these folders a perfect target. Moreover, a lot of plugins have their own vulnerabilities. Another way hackers install backdoors, is by adding a new plugin to the site that looks normal, but is actually malware.

Just to give you a general idea, this is how you identify a backdoor (that looks like a plugin file):


These vulnerabilities are sneaky. They can be passed off by a number of malware scanners as legitimate files, because of the way they’re named. This is why it’s so difficult to identify backdoors.

Backdoors are especially infuriating because sometimes hackers choose to leave more than one of them, in many locations. So even if one was discovered, there would be another way in.
Accurate, efficient scanning and hack removal requires time, and technical assistance (which is expensive usually). If you’d like to test the only one-click, automated hack-cleaner that misses nothing, and sounds no false alarms, we suggest that you try MalCare, for free.

Having your website hacked could be compared to having an annoying roommate sometimes. Everything’s a mess, no matter how many times you keep putting things back. Your shampoo, food and other resources are always running out. Thanks to them, shows you’ve never even heard of turn up in your ‘Continue Watching’ list on Netflix… And to top it, none of your friends want to come over any more.

But that’s where the similarities end.

You can always talk things out with a roommate, or probably move out… But hacks have devastating consequences. And there’s no way you can just end the problem by walking out. Your website’s reputation is at stake, and the internet never forgets.


There are a number of reasons hackers attack your WordPress website even when they know nothing about you, or what your site stands for. In fact, most of the time, hackers use crawler bots, like the ones search-engines use, to check the web for sites that exhibit vulnerabilities.

Once they identify weak websites, hackers attack for one of the following reasons:

  • They want to gain critical information from the website. (This could be any sensitive information, like login credentials)
  • Modifying your site allows them to serve your visitors malicious content (like viruses, or malicious code that could track your visitor’s cookies)
    • Defacing a website helps hackers send some sort of message across. These kinds of attacks make up for only a small number of hacks
  • Your website could be another notch in the hacker’s belt: damaging your website could help them climb ranks in the hacker community
  • Exploiting your site’s resources could prove to get them some kind of monetary benefit. Stealing your visitors identities and selling them on the web is something a lot of hackers do. Hackers could also try to gain control of your server, in which case they could do anything.

Once an attacker gains control of your server, the amount of power they wield depends only on what they want to do. They could do anything from sending out spam mail, to even deleting your website. In fact, some malware is designed to lock you out of your website until you give in to the hacker’s demands. Malware designed for this purpose, is called ransomware, (for obvious reasons). The data stolen from websites could also be held for ransom. Hackers could declare to release it in case their terms of payment isn’t met. But those are headline-worthy scenarios… What hackers stand to gain by remaining undetected, is a lot more. Undetected hacks mean that hackers could keep siphoning off information, and using it for their own purposes.

In fact, the Netflix scenario we mentioned earlier actually happened earlier this year. Netflix users’ login credentials were stolen after the site got hacked, and then sold on the web. Identity theft is a huge business, and hacks like these thrive on the premise that the website owner isn’t in the know. So even if you’re only a WordPress site owner who has subscribers, you have reason to worry.

It’s  been a while since WordPress core has had any vulnerabilities, but plugins and themes are a different story altogether. Developers creating these plugins and themes usually don’t anticipate the exploitation of vulnerabilities… or they build first, and then fix later. But with hackers becoming more and more competent, hacks keep getting more complex, and difficult to identify.

Most vulnerabilities open doorways to other exploits and attacks, each with their own scope of damage. The cumulative damage could be disastrous for you, as a WordPress website owner. Moreover, your site could keep getting hacked because of exploits like Backdoors. They maintain a foothold to your website’s server, and your website.

This is why security options like WordPress firewalls, and antiviruses make sense. You’ll have to notice that something is wrong first though, (and do it fast).