I think the people working in this space are pretty good at making their ideas freely accessible. Mostly because we don't seem to assign much value to making things secure :(
Speaking only for myself, I am really tinfoil about security.
However, it’s not my area of expertise, so I probably go way overboard on it.
It’s because of the types of users of the apps I make.
My apps are mostly free apps, meant to be used by recovering addicts, and that demographic is (justifiably) paranoid. Lots of people hate addicts, and actually don’t want them to recover. They want them dead (except for my little Muffy, who is just an addict, because of her boyfriend, who we want dead).
If that sounds like I’m cynical, it’s because I am. I’ve been Serving this demographic for over 40 years, and have seen a lot. I’ve authored a lot of stuff that has become infrastructure.
In any case, I do my best to provide very secure software.
In the app I currently maintain, I went pretty crazy, in the backend server. It has multiple layers of security, and a lot of work to defang stuff like privilege escalation, and (of course), SQL injection. A lot of filtering is done in the actual SQL, for example. Many coders bring the information into memory, then filter it. I do my best to make sure it never even comes out of the database, if the current user isn’t authorized. I’ll do things like reload the user privileges, just before any SQL access. I also relegate all DB interactions to two extremely low abstraction layers. This has the added benefit of allowing me to swap DB technologies, in the future, if I want. Of course, I also use PDO, at the DB level, which gives me choices, there.
And the DB schema is crazy simple. No relations. I use a token-based authentication system, parsed by SQL code, so there’s no ACLs to hack. This also means that I have choices in DB engines, in the future, as the data are little more than Key/Value stores.
And I try to never have anything to do with that code. It’s simple and basic, so it updates really well with new PHP versions. I suspect most of the code would work with PHP 5. I use PDO Prepared Statements, when executing even the simplest queries, and I use Transactions, for DBs that support it. I have separate DBs for security and for main data, so there’s a security DB that can be sequestered and tracked/audited.
While I was developing the server, I went pretty crazy, with the testing. Each layer was subjected to thousands of probes and attacks, at varying levels, on millions of dummy records (I’ll probably never have more than a couple of thousand users), before I went on to the next one. I worked on it for over seven months, before I wrote one line of Swift. I’m big on testing.
If that sounds complicated, it actually isn’t, if you follow the architectural rules, but because it’s embedded into a very, very simple, low-level, abstraction, it almost never needs to be accessed.
I avoid working on the backend, because I basically hate PHP, and server-level work. I prefer spending my time, making users happy, at the UX level, with native Swift clients. I do overkill, on the low-level, so I don’t have to worry about it.
But probably, the best security, is that I don’t actually store that much user data, and don’t do things like data mining on the bit that I do store. We have a fairly strict privacy policy, that I treat as Canon Law. My partners don’t really like it, but I’m an uncompromising S. O. B.
I respect the effort you put into your apps but I caution you that people who are looking to find exploits in your software are definitely looking at things you are not covering here.
