1. make a setup plan
Setting up code for a website, where the public will eventually have access to all the data in the database does require a different setup from a web based application that holds privicy-sensitive data. On the other hand a website that is open to the public literally exposes your code to all the hackers of the world. So take your time to think about your requirements and the threats you are going to face.
2. check your application thoroughly
Php has several commands that can put your server's sercurity at risk if called with the wrong parameters. MySQL may allow your queries to call shell commands, or do other things you do not intend to happen. Make sure no user input from the request, forms, cookies and the session can silently enter into any parameters of these functions or your SLQ queries.
Be aware that the warnings issued by certain commands and phpPeanuts methods will not stop execution so that unexpected results like a SQL delete query without a where clause may be the result.
Check that your application does not inlcude any development code that you only entered for testing or debugging. Consider to do an automated search of your application for sercurity-sensitive function calls.
Be aware that phpPeanuts' generic SaveAction, DeleteAction and DeleteMarkedAction may be abused by malicious users ot others thay have access to modify or delete data, even if the forms to call upon them are not availble in your application. If you do not want this, you may have to add code to prevent this to these classes, their specialized counterparts, or Site::forwardRequest.
2. set up access control before you start uploading
While you are installing you application may be more vurnerable to attacks then after you have completed and tested it. Most web servers and hosting account nowadays offer access control, so there is no need to take these risks.
3. check ErrorHandler to be set up properly
PntErrorHandler may reveal a lot if information on the internals of your application if it is running in development mode. Be sure it is properly configured for production and once it is installed, test that it actually does not show debugging information but instead, logs the error and forwards to a not-informativer error page.
4. do not install any development tools in production
Development tools like pnt/unit (came with phpPeanuts) and the examples are probably not needed in a production environment. As you may know, all software contains bugs. If you have no need for certain code on your production server, it can only do harm to upload it. Especially if it has a user interface. Especially if it has not been developed for production situations. So don't upload these tools.
5. keep a copy on your development server for debugging and maintenance
If eventually you find a bug or an unexpected error gets logged, do not try to debug it on you production server. Use your development server to reproduce it. Then debug it on your development server. Then check your changes thorougly before you upload, in the same way you checked you application. Also check them not to conflict with your original setup plan. Consider to backup your database before you expose your data to a modified application. Consider to add access control for the duration of the uploading and integration testing. Test your changes again after uploading before you return to normal access control. |
