Four steps to prevent your developer taking over your website
Comparison site GoSwitch was vandalised after a developer locked out the owners of the site and used it to air grievances. Here Ben May sets out four rules to follow to stop the same thing happening to your brand.
If there’s a lesson to be learned from the events with GoSwitch, it’s that entrusting your website to a development partner – whether it’s a large agency, micro studio or a freelancer – can be riskier than it appears.
Like many things in life, it comes down to managing relationships and building mutual trust and respect between both parties.
There is nothing you can do from preventing someone with unrestricted access to your systems from going rogue and defacing them, or worse.
GoSwitch was hacked by a developer claiming he had not been paid by its agency
While having a social media account hijacked and stolen is a quick way to do some damage to a person, company or brand, there are pathways to recovering and moving on.
Having a website defaced or vandalised is far more complex, as there is no authority policing your site. The buck stops with you.
There are however some simple things you can do to ensure your exposure is limited and, in the event something like that happens, you can respond quickly, recover and move on.
1. User Accounts
If your site is powered by a content management system such as WordPress, Drupal, Joomla et al, then it’s important that you have the most privileged user account. Your website developer or agency should not have an account higher than yours.
Even if you don’t use that administrator account for day to day operations, you don’t want to find yourself locked out or unable to remove user accounts.
It’s important you periodically review those with administrator access to your website.
2. Hosting Account Credentials
Hosting account credentials (eg, FTP or SSH etc) should reside with the owner of the website. It should be kept secure and shared with only those who absolutely need it. It should be reset regularly, or whenever someone leaves the organisation.
It may not be as easy, but security experts warn against one shared login and password. If possible, give staff, contractors and agencies unique accounts so they can be easily tracked and revoked if needed.
3. Hosting Account Ownership
If your site is served by a fully hosted platform (eg WordPress.com, Squarespace, Business Catalyst), you should have this account under your own name and email address. In the event of a dispute, you’re able to talk to the provider and seek their assistance in regaining control.
If your site is run on your own infrastructure any contracts should be in the name of the site owner, who is also listed as principal administrative contact.
Contractors, staff or agencies should be registered as technical contacts who have permission to act on your behalf, but the ownership and final control of those services should lie with you. You’ll then have the power to easily remove third party users access and protect yourself.
4. Domain Name Ownership
In the event you’ve paid an agency who has total control of your hosting, your website and its content, the last asset (and potentially most valuable) is your domain name.
So often we see agencies buying and registering domains under their own ABN and not that of the client.
Australian domains should be registered under the site owner’s ABN/ACN and the registrant contact should be the site owner, not a third party. This means the domain name can be recovered in the event of a worst case scenario.
For more and more businesses their website is one of – if not the – most important asset and should be treated as such.
Although there are a number of other factors to be considered when securing your site and disaster recovery, establishing the correct access and ownership is an important place to start.
- Ben May is general manager of The Code Company. Mumbrella is among his clients
I remember back in my student days when my little freelance web dev operation would get constantly screwed over by SME clients. I made sure I had full control for these very reasons, it made for great leverage when negotiating outstanding accounts.
User ID not verified.
Pay your developer…
User ID not verified.
Or you know… I could make sure I actually pay the developer…
User ID not verified.
The key to running outsources teams is to be good at managing the relationship. It’s pretty clear that the guy affected was bad at it and he paid the price.
For $3,000, it’s worth just paying them as you really don’t want a horde of enemies causing your downfall.
User ID not verified.
1. Pay your suppliers
2. Pay your suppliers
3. Pay your suppliers
4. Pay your suppliers
User ID not verified.
“Pay your developer” was implied under the whole “building mutual trust and respect” thing.
Agree, nothing worse than having someone “going rouge”!
User ID not verified.
I’m sure everyone was seeing red over this, but I think you mean rogue (aberrant) not rouge (red) in par 3.
User ID not verified.
It is absolutely critical that you retain control of your domain name and its DNS records. If you do nothing else, do this.
Once you lose control of those records, you’ve lost control of everything.
User ID not verified.
Penguin, does that include losing control of your bowels?
User ID not verified.
JG: Post your registrar/DNS account login details here to find out!
User ID not verified.