Не выпускайте релиз в состоянии полу-готовности

Часто возникает желание сделать что-то по минимуму, а позже все это исправить. То есть, выпустить сырой продукт, а об удобстве «позаботится позже». Это плохая идея. Во-первых, когда с самого начала что-то не работает, ваши пользователи вряд ли испытают чувство благодарности и доверия к новой CMS. Во-вторых, устранение проблем в дальнейшем будет требовать от пользователей повторно изучать систему. В-третьих, это «позже» вряд ли произойдет, к тому же, если покупатели уже вложили деньги в покупку/разработку CMS, они, естественно, ожидают результата в лучшем виде.

Все это не исключает возможности постоянного совершенствования системы, включая пользовательский интерфейс, но это означает, что CMS должна быть годной к использованию и удобной с момента выхода. Потребности пользователя необходимо учитывать при планировании и разработке CMS, их нельзя оставлять на конец, в противном случае у вас никогда не будет достаточного времени или ресурсов для их удовлетворения.

Вовлеките дизайнера в процесс

Не оставляйте дизайн пользовательского интерфейса разработчикам, которые создают и устанавливают систему. Даже если они обладают необходимыми навыками для разработки интерфейса, они не смогут удержать в поле зрения дальнейшие перспективы развития, поскольку они слишком вовлечены в рутинные детали при разработке CMS. Даже опытным практикам юзабилити трудно держать в поле зрения конечных пользователей, они слишком сосредоточены на технических сложностях создания системы.

Большинство компаний не думают о том, чтобы использовать своих графических дизайнеров или юзабилистов как инструмент на пути к конечному продукту. Но они недооценивает важность этого инструмента, особенно если речь идет о крупном сайте.

Tips & tricks по безопасности в сети

HTML
Да да, я не опечатался. Первое что напишут на сайте на котором разрешен html - будет ХУЙ. Ну может быть не первое, но напишут обязательно. В принципе если детям ваш сайт неинтересен - это не так уж и страшно, но согласитесь неприятно. htmlspechialchars(все_входные_параметры)
И никаких хуёв на главной

Троянские кони
Казолось бы причем тут лошадки? Ну если у вас есть модераторы - наверняка среди них встретится любитель тыкать по ссылкам в ИЕ6. Украв куку целиком - никакие шифрования не помогут. Но у нас ещё остаются сессии. В сессии можно хранить кучу ненужной информации, например IP пользователя, User Agent и валидировать их с кукисами. Тогда украв куку - хакеру ещё нужно будет украсть и айпи и браузер жертвы, что уже немного сложнее.

Печеньки
Кукис хранятся на клиенте, и значит по определению являются неблагонадёжным источником информации. К счастью никто уже не хранит в кукис пароли в явном виде, но password:MD5(password) - встречается повсеместно. Во первых хэш пароля 1234 наверно лежит наверно в топе гугля, во вторых, кто вас за язык тянет называть переменные своими именами? Итак, пароли хэшируем как то так MD5('1234'+'$%^x_Yl1234_?kl%$'), где "'$%^x_Yl1234_?kl%$'" - генерируем ударом лба об клавиатуру. 2 - не пишем как идиоты логин, пароль и т.п. в куки. Лучше глобально зашифровать всё её содержимое.

Картинки
Дадат, невинные картинки могут содержать как невинные текстовые комментарии, так и безобидные скрипты. Если вы посмотрите на адрес картинки в заголовке поста и подумаете что это "пальцы" - то ошибетесь. Делать мне нечего - плодить субдомены. Просто на субдомене можно банально запретить все php, cgi и пр. скрипты. Или даже поставить какой-ть нджиникс. Помимо запрета скриптов мы таким образом ещё и скрываем абсолютный путь к папке с картинками.