Secure file organization

The following page is about securely organizing your files.

1. Use .pm as a rule, .vm as an exception
   Make every Velocity file a .pm file. Only if a file should be able to be opened from anywhere, make it a .vm file. Always use .pm files for:
   1. Helpers, like calculations
   2. Templates
   3. Headers and footers of classes and sections
   4. Files that are only parsed
   Only use .vm's for pages that can be called directly from outside of the application. For Ajax calls, use .am files.
2. Be explicit about permissions when using .vm files
   When using .vm files, think about which usergroups should be able to use the file. To do this, make use of the file permission system. Older .vm files may still have permission logic in their first few lines. If a .vm file has no file permissions set, and no permission logic in the first few lines of the file, this needs attention!
3. Think about the application of permissions when using scripts
   Realise that in .vm files permissions are not automatically applied. Any Velocity method that returns data, has access to ALL data. Permissions have to be applied explicitly. When using queries for instance, this can be done by calling setApplyReadPermission(true).
4. Never get test data in a file used on production data
   To test a file, the best practice is to use a separate file. We have seen examples of calculations in .vm files where the record for the calculation could be determined by an id from the request. Although this isn't directly harmful. If this file makes it's way to production it poses a security threat as anyone can now run this calculation with any record by supplying their own record id to the request.
   Another unsafe testing method is providing a hard coded testing id if no user is present, eg. id = 6. If this file makes it to a production environment, then the person record with id = 6 may not be a test user!