All Corinis modules have a security layer which checks:

• SQL-based hacks: All Strings are escaped, you cannot enter any sql-escape commands to modify the database. There are also field checks that prevent unallowed fields or tables to be accessed.
  
• Session spoofing/hijacking: The session is always connected with the ip and the application name. You can not use the same session on more than one computer, this way no one can simple fetch your session. The same restriction applies to autologin cookies. These are also bound on an ip address and can not be used on a different one.
• permanent login cookie: In order to prevent the stealing of the permanent (or auto-)login cookie, the cookie is bound to an ip. Only if the ip and the cookie are correct, the user will be authenticated.
  
• Upload malicious files: The file upload module prevents certain files from being uploaded (like .php, .jsp, .cgi). You can expand this list in your configuration XML
• Unallowed function usage: Since the view/create/modify/delete functions are seperated and normally seperately implemented, a user (even if he finds out a more preveliged username/password) can not simply change something unless he has access to the administration pages

The corinis authority management allows easy administration of hundrets of users/groups with detailed rights for special elements.

This is possible by:

• each user can be in multiple authority groups/roles
• each group can be in another group, getting all authorities from the groups below (hierarchical system)
• each user/group can have multiple "function rights" and/or element rights
• every function checks if the user accessing it has the right to do so (a user without the CMS_MODIFY right is not allowed to call any functions that would modify a document/folder in the cms)
• some modules also check for element rights. This way you can specify if a user can read/write/modify/delete/... certain elements. The administration of element rights happens on the element, while the function rights are givin the user/group administration.

By having seperate rights for function usage and elements you (as an admin) have full control over what your users do on your site.

The administration pages are accessible by all users, but a user can only see the administration if he has certain rights (you will not see the Cms module if you do not have at least CMS_DOCUMENT_EDIT). If you want to secure your site you should move the administration from the default directory (/corinis) or put an additional .htaccess file into it. It may also be a good idea to have the administration on a differen vhost then the normal site (corinis.yoursite.tld or admin.yoursite.tld ).

When implementing a site, you should only call functions that are absolutely necessary (in a normal implementation you would never call CmsEdit.deleteEntry in a normal site). This way it is impossible to access certain functions even if a potential hacker hijacks a user and knows the request parameter to change something.

In the next releases security will be tighten even more by implementing:

• https checks for the administration: You can specify to allow the administration pages to run ONLY over a https secured host (this might also include admin-only functions to do internal checks)
  
• IP ban for functions/whole site: an ip blacklisting system will be included so you can disable certain functions/modules based on ip
• complete site logging/event notification: there is already an eventer module integrated in all modules. This will be used to create a site wide logging module. You will also be able to be notified by email/other modules if certain events happen (a non whitelisted ip logs in with your user, ...)