Not a lot of thought wrote:I'd like to have a layer of code that checks to verify that nature of the information isn't malicous, firewall, prevent brute force hacking, etc. I'm not sure if those are legitimate concerns, but I'm open to opinions and ideas.
Those are very legitimate concerns. Indeed, those who believe they're not are the companies we read about every week in the newspapers whose servers got hacked. And unfortunately, while most of the well publicized exploits had some really dumb human error at their origin (using WinXP well past EOL, passwords leaked through social engineering, server rooms left unlocked, etc.) no matter how much we harden our systems there is always some hacker out there with an IQ twice as large as ours who's trying to break in, and if sufficiently motivated they will inevitably succeed.
Security isn't a single layer, but a mindset that influences all layers. Shawn's right in suggesting that hardening the server itself requires an admin experienced in that, but it doesn't stop there. Every aspect of any system connected to the Internet needs to be written with security in mind, since the system as a whole is only as secure as its least secure element.
One common practice is to put a layer between the database and the outside world. Whether that layer is PHP, Python, LiveCode Server, or something else matters less than that it's used conscientiously. Such a layer not only simplifies data management and presentation, but can also sanitize inputs to make sure unwanted file paths or instructions aren't injected into the system, e.g.:
Since such a layer is technically a multi-tier ("n-tier") solution, you'll also score on the Buzzword Bingo scale.
But then there are things that aren't specific to any single layer that are also important. Passwords, for instance. Good practice is to never store them, but instead store a hash of them. With LC's sha1Digest that seems easy enough, but to avoid brute-force cracks they'll need to be salted as well - and there's a lot of disagreement about what constitutes "best" salting methods.
To get a feel for how complicated password salting can be, this is a useful if frightening read:
http://arstechnica.com/security/2013/05 ... passwords/
And then there's session management, and the implications for session fixation if an interloper can obtain a session ID.
And the little things, like dynamic execution using "do" (or in Node.js "eval"), which can be useful in sophisticated systems that support a wide range of actions, but it may be possible to inject arbitrary instructions into the system unless all incoming arguments are diligently checked.
And of course SSL. Consider it a minimum for any secure system, and keep it up to date so you can stay on top of possible issues like the next HeartBleed bug. It can be tempting to encrypt data in transit yourself, and if you're using a shared-key system that may be a good option, but most systems will negotiate a password and that's a job well suited for SSL. Like they say, avoid reinventing security components where you can.
There's more, but all of that's just on the hardening side, and that's only part of a complete security breakfast. The other two aspects of security are monitoring and recovery.
Monitoring with a cron job to double-check that the system is working normally can alert you if the system is disrupted, useful not only for discovering oddities that may have been introduced by hackers, but also general availability for a good customer experience. Servers go down. Once in a while (thought it's not common) Apache needs to be restarted. If you discover that before your customers do it'll save some angry emails. Even better if that cron job is run from another server outside the server farm to avoid a single point of failure.
Recovery acknowledges that every system can be hacked, and proactively assumes it will be. So data is backed up regularly, with methods for ensuring the integrity of the backups, and restoration is not just a plan but something that has been rehearsed (too many systems have what seems like a good recovery plan but they don't find out that it's broken until they need it, and then it's too late).
All this may sound scary, and I suppose it is. But don't worry: everyone gets it wrong.
After all, even Sony, Apple, BestBuy, and others, with armies of highly-compensated specialists, get hacked. Even the Pentagon has been hacked. Everything is hackable.
Just learn what you can, be willing to constantly apply what you're learning to make the system ever more secure, and that'll get you started.
If budget permits, I can't speak highly enough about the value of hiring a penetration testing consultant. That's not a service I provide, but I've met some good ones and may be able to make a referral if desired. Having someone unfamiliar with the system trying to break in can help you discover possible weak points that an earnest developer just trying to deliver features might never have noticed.
And sometimes just doing code reviews with another experienced developer is helpful. Someone outside the day-to-day development tasks may see things in a way that wasn't obvious when the code was written with one eye on the clock. Peer review is becoming ever more popular with agile methods these days, and for many good reasons, not the least of which is to provide a second person familiar with the details of the system in case something needs immediate attention while you're on vacation.