1. Комплексная защита
Одним из основных принципов грамотной организации безопасности веб-приложения является комплексная защита. Дело в том, что проблема защиты программы отнюдь не ограничивается только обеспечением защиты отдельных cgi-скриптов. Само приложение может быть написано абсолютно правильно, без каких-либо ошибок, однако, при этом установлено на неграмотно конфигурируемый сервер, например, с настройками по умолчанию. В результате, такая программа может быть взломана даже без использования веб-скриптов.
Основываясь на этом примере можно сделать вполне логичный вывод, что безопасным должно быть не только само приложение, но и конфигурация сервера и каждое стороннее приложение, установленное на сервере и сама ОС сервера и т.д.
Специалисты, обслуживающие работу какого-либо конкретного веб-приложения всегда должны работать вместе, как единая команда. На практике довольно часто встречается случай, ставший уже почти хрестоматийным: программист решает, что для удобства работы программы необходимо открыть какую-либо конкретную папку на чтение/запись для всех пользователей. В этой папке скрипты приложения будут записывать итоги своей работы. Одновременно с этим администратор сервера использует эту папку для хранения настроек доступа к веб-серверу. Вполне понятно, что в данном случае весь сервер и приложение в частности оказываются под угрозой.

2. Права доступа.
Пользователи.
При организации безопасности веб-приложения всегда следует отталкиваться от жесткого правила "запрещено все, что не разрешено". При применении данного правила на практике абсолютно верными являются действия, когда в начале проектировки приложения запрещается абсолютно все, а затем по мере необходимости, открываются нужные каждому пользователю права.
Скрипты.
Скрипты в веб-системе должны всегда выполнятся с минимально-необходимыми полномочиями. Все сценарии выполняются веб-сервером, как правило, это Apache, и, следовательно, именного его правами определяются права выполняемых сценариев. При решении проблемы полномочий скриптов, наиболее эффективным методом является создание отдельной учетной записи на веб-сервере с минимальными полномочиями и организация запуска скриптов от имени данной учетной записи.
Пользователи сервера Базы Данных.
Правильное администрирование прав доступа пользователей БД является одним из важнейших моментов организации безопасности веб-приложения и позволяет уберечься от многих неприятных сюрпризов. Однако большинство разработчиков пренебрегают данным аспектом, всецело полагаясь на аутентификацию пользователей на уровне самого приложения.
Практически все веб-приложения делятся на 2 части - клиентскую и административную. Вполне логично соответствующим образом разделить и скрипты приложения. Скрипты клиентской части чаще всего используют один вид запросов к БД - оператор SELECT, значительно реже операции - INSERT и UPDATE, очень редко - DELETE и практически никогда - DROP и ALTER. С другой стороны, администратор может часто работать со структурой БД и выполнять запросы DROP и ALTER не реже, чем SELECT. Данная особенность может быть с успехом реализована в защите приложения путем создания различных учетных записей БД для отдельных групп пользователей приложения. Например, для пользователей клиентской части можно разрешить только выполнение оператора SELECT, а для администратора абсолютно всех операторов. Таким образом, если даже хакер и подберет пароль для пользователя клиентской части, ни удалить, ни изменить данные он не сможет.

3. Пароли.
Одним из базовых правил системы безопасности являются сложные пароли. При решении данной проблемы приходится всегда учитывать два аспекта - с одной стороны - удобство пользователя (то, насколько пароль запоминаем, удобен в наборе и т.д.) и, с другой, безопасность системы.
Как правило, сам пароль либо придумывается пользователем, либо генерируется системой автоматически. Первый вариант удобен для человека, второй обеспечивает гораздо большую безопасность. Как правило, пароли, создание которых отдается пользователю, подбираются хакером довольно легко. Люди не любят надолго задумываться над паролем, и вводят первое, что придет на ум, это может быть либо дата рождения пользователя, либо знаменитое "qwerty", либо просто набор единиц. Даже, если пользователь придумывает какой-либо сторонний пароль, почти всегда, это слово, и такие пароли подбираются хакером перебором по словарю. Гораздо сложнее подобрать пароль, сгенерированный системой автоматически, зачастую, это набор 10-12 никак не связанных друг с другом знаков. Такой пароль перебором подобрать практически невозможно, поэтому он гораздо более надежен. Но и в этом аспекте есть недостатки, например, почти анекдотичный случай, когда пользователь, будучи не в силах запомнить 12 случайных букв, записывает пароль на бумажку и клеит к себе на монитор. Если компьютер рабочий, пароль могут получить немалое количество человек.

Реализация перечисленных принципов безопасность системы не гарантирует на сто процентов и, скорее, всего, опытного хакера, задавшегося целью ее взломать, не остановит. Однако столь простые правила, о которых часто забывают, позволяют поднять безопасность системы на довольно неплохой уровень и оградить себя от быстрого взлома.
Следует отметить, что абсолютно защищенных систем не бывает в принципе. Если есть защита, ее всегда можно сломать. Однако, все дело в количестве ресурсов (как правило, временных), затрачиваемых на взлом. Если вы создаете форум и обеспечите его защитой по вышеописанным принципам, он будет защищен на 100% - быстро его не сломаешь, а долго возится там не за что. Максимум, что можно сделать, взломав форум, разместить там свои страницы или украсть почтовый ящик. А вот, если проектируется система электронных платежей, там есть за что повозиться - номера кредитных карточек того стоят, поэтому защита таких приложений ведется на гораздо более сложном уровне.