When "defaults" don't cut it
For those who are more my age (suffice it to say, I'm still in my 50s...just!), and took to computing back in our 20s, we remember having to configure EVERYTHING! "Plug-n-play" wasn't even thought of back then, let alone dreamed about. But it did give those of us with some skills the chance to tweak and fiddle. While I, mostly, welcome the new age in computing where things just work (unless they don't!), these advances have made us lazy and un-attuned to potential threats to security. Most of us don't want to spend time setting up a piece of equipment or a software program, we demand that it works "Straight-out-of-the-box" without any intervention by us. I certainly like that for almost all equipment, but for software, that's a different matter.
Why "out-of-the-box" settings can be bad
While this post can be related to any sort of software, it really references web design extensions. Apart from the fact that we're web designers, these extensions present hackers with their best opportunities for data theft. While doing updates on one of the sites we manage this week, the backup extension we use (for obvious reasons we aren't going to name it!) gave us a warning that we were using the default output directory. The output directory (or folder) is where the backup is written to during the backup process, and, because that resides in the public directory (/home/<site_name>/public_html) it is potentially visible to hackers. If someone gets access to that directory, they could download copies of your site which will include any secure data - like usernames and passwords - you want to keep secret.
Or maybe your site has premium or members-only content, kept secure behind password protection. If a hacker gets a copy of your site, all that's in plain sight!
Why would a programmer write in such an unsafe manner?
That's a valid question, with an easy answer.
Just like no 2 humans are alike, no 2 server setups are alike either. It would be impossible for a software developer to understand your particular setup and adapt the settings to suit. Even if they could figure it out, how can we be sure they'd get it right every time? So they code in "defaults", in this case, a default output directory for these temporary or permanent files to reside in. Most importantly, for security reasons, their access to your server is restricted to /public_html, so that's where they have to make their default folders.
So we now have the unfortunate situation where a developer needs to output data to a folder, but only has access to /public_html.. what can they do, but write to that?
Is my website's backup data unsafe?
That's also valid question, with a not-so-easy answer. Or, "it depends...."
It depends on how your backup software works. Many write, at least temporarily, to a temporary directory (usually something like /temp or /tmp) during processing. Some will store data their permanently afterwards. If you backup software does either of these, yes, your data can be at risk if that directory is under /public_html.Even if you don't store data there permanently, hackers could get access to temporary files created during the backup process (even if they're deleted at the end) and obtain data that way.
Is there any way to protect from this?
That's another valid question, fortunately, also with an easy answer!
You'll note that we referred to /public_html (the public directories) throughout the article. The way we secure these sensitive directories is to place them outside the public area. So, we make the output directory directly under the root, or /home, directory. Therefore, we can make the directory, for example, /home/my_output_directory. As it's outside /public_html it's invisible to anyone trying to scan directories.
But...isn't there ALWAYS a but? For this to happen, you need to know that you have to do it and know HOW to do it, or your web developer does (and they need to care, or at least care enough if you pay them to do it). Knowledge maybe power sometimes, but not in this case. Knowledge is only power if you know how to put it to use and actually do it. Otherwise all it does is give you ulcers thinking about how unsafe your website might be.
Good news for our clients
When we set up CitrusKiwi, we determined to provide a unique service. One where paying a small monthly fee passed the hard part of building and maintaining a website off to someone else - someone with the skills and time to do it, and do it right and efficiently. So, while the likelihood of a data breach this way is small, why take the chance. We're just finishing up updating all our clients' setups to put this sensitive data outside /public_html and away from prying eyes. They don't even know we've done it and it doesn't cost them a dime! That's the CitrusKiwi way of doing good business.
If you'd like a fully managed website at a price you have never dreamed of, check out our plans and see the value they offer to business-owners who really care what's happening with their sites.