Secure your code: general principles

Some of de most basic and useful general principles of programming must be applied when approaching security matters in your code.

Stay DRY (Do not Repeat Yourself)

More than unproductive, repeating yourself when implementing security is dangerous. Bugs have more room to spread and remain undetected (slipping between a copy and a paste or two .hg commits ). Attackers get more chances to see your code.

Continue reading

Food for thought

Security is imperfect

Just like anything else, all security mechanisms are inherently flawed, the only thing that separates good security from bad security is the degree of work an attacker has to do in order to by-pass it. A security mechanism cannot be perfect, but it has to be at least good enough for the purpose.

Security is not some “self contained” entity

But a chain of mechanisms, governed by a set of practices, used (and abused) by an unpredictable number of unknown users (and abusers). Any secure system is just as secure as its weakest link. When that link fails, security is compromised.

Continue reading

Layers and levels of security

Layers of security

A well conceived security system operates on different layers, hence reducing the chance of complete and catastrophic breach when one layer has failed. It doesn’t mean that isn’t still possible, just that the chances are significantly reduced by putting the burden of security on more than one subsystem, on more than one level.

Web server

Offers the logistics required to protect your directories and files from (unautorized) access, serving to the outside world only what it is supposed to get. Secure your web server!

Continue reading

Secure the database server

The MySQL server has its own security mechanisms in place, via user-based access, as far as table level, with per-operation authorization (you can grant access to a certain table only, to a certain user, only allowing SELECT operations).

See securing the web server, for general MySQL administrator account guideliness. In addition:

  • do not re-use your root account credentials in your scripts! This way, there’s no need to store these on the file system. Instead, create a separate database for the purpose of your website/application, create an user account (with the relevant privileges) for that database only, and store these credentials on the file system (as securely as possible). If your application requires multiple databases, either do the same for each (possibly having a single set of credentials for all of them), or create an user that can create databases, but without the other root privileges.
  • make sure your admin credentials are not the same as those for cpanel or FTP access, nor are they the same as those you use in your system’s user management interface

Secure the web/FTP server

The web server software configuration is largely managed by your web host. They are the ones responsible for the “general” securing of the web server. However, that does not mean (at all), that your system, whose interface is output by the webserver, is automatically secure. That is why you need to take extra steps to secure your system, using what the web server has to offer. Some of these may seem childishly obvious or simplistic. Regardless, just make sure you have it covered.

Continue reading

Secure PHP

For the purpose of this tutorial, the PHP engine provides the development environment. There are many features of it that present significant security risks and should be disabled. Lately, they are disabled by default in the newer versions on PHP.

Securing your PHP must include:

  • turn off register_globals: put register_globals = Off in your php.ini, or use ini_set(‘register_globals’, ‘Off’) in your code, or put php_flag register_globals 0 in your .htaccess
  • turn off magic_quotes: put magic_quotes_gpc = Off, magic_quotes_runtime = Off, magic_quotes_sybase = Off in your php.ini, or do it the ini_set() or .htaccess way (see above).
  • turn off allow_url_fopen and allow_url_include if you don’t need to read files via URLs (usually from other servers)
  • set error_reporting level to 0, thus preventing error messages, potentially containing sensitive information, such as database keys, user passwords, etc., from being displayed in browsers; put error_reporting = 0 in your php.ini, or do it the ini_set() or .htaccess way.

Continue reading


Website security

Or web application security, or, more generally, system security, is a conglomerate of mechanisms and practices aimed at protecting the integrity and privacy of the system and its users. There are many layers of security, and many ways too look at them. This document looks at security from the position of website/web application developer (i.e. it is less relevant for web/database server administrors).

Continue reading

Friedrich Nietzsche “The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.”

Friedrich Nietzsche, philosopher (1844 – 1900)

Seth Godin “Tribes are what matter now.”

Seth Godin, marketer (1960-present)

Nothing new.

Staying in sync with the present time is not that big a deal. Keeping your eyes open, your ears keen, and your reflexes intact isn’t particularly difficult. Following your herd is not something hard (or something to be proud of). Most people are on Facebook and Twitter. I’m not. It’s not that I’m not “most people” (which I’m not), it’s that I’m not in sync with my times.

Sometimes, to be ahead of your times, you need to live in the past.


In a seaside town, on a sunny week, at work. Always at work, then back “home” at more work, under never-ending stress, playing Atlas all the time. Not today. Against all ods, today will be a day for sea toe-dipping, plenty of sun burns and a few seaside glasses.

Sometimes you have to stop and smell the seagulls.