Short answer

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

Long answer

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include andrequire. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

The incredible lightness of living outside the fence

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

Joomla! defense

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

The challenge

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you can not forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:

1. First allow all access, then deny any username/password combination that DOES NOT match the approved list.
2. First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

The good news

1. In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
2. Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
3. Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.