Handling sensitive data
What the exam tests
Sensitive data handling is about classifying data, minimizing collection, protecting it at rest and in transit, and preventing leaks through UI, logs, and errors. OutSystems gives you platform controls, but design decisions determine whether they work.
Core rules
- Classify data first: credentials, personal data, financial data, and health data need different controls. Collect only what the process needs.
- Store secrets in secure configuration, not in code, comments, or ordinary site properties that broad roles can read. Restrict who can edit and view them.
- Encrypt sensitive attributes with supported platform features or a vetted cryptographic component. Use platform-managed password hashing for credentials; do not invent custom cryptography.
- Restrict entity permissions so only required roles can read sensitive records. Mask values in lists and screens, for example showing only the last four digits.
- Sanitize output to prevent cross-site scripting, and use parameterized queries or aggregates rather than string-concatenated SQL.
- Keep sensitive values out of logs, error messages, and analytics. Audit access to sensitive records and define retention.
Worked example
An app stores a tax identifier. The team encrypts the attribute, grants Read only to the Finance role, masks the value in the list screen, and excludes it from logs and error detail. They add a retention job that purges records after the legal period. Reasoning: encryption alone does not stop an over-privileged user or a log leak; controls must cover storage, access, display, and lifecycle.
Traps
- Putting API keys in site properties readable by all developers.
- Logging full request bodies that contain tokens or personal data.
- Returning stack traces to users.
- Caching sensitive pages or responses in shared proxies.