AJM Softwares · Technical note
Define the system and its risks
Map the application’s user roles, sensitive information, important business actions, APIs, external services, and production environment. Start with what could happen if information were exposed, altered, or unavailable, then set the review scope around those risks.
Record what the system is expected to do before testing it. A standard such as OWASP ASVS can help teams define and verify technical security requirements, while the business rules still need to be understood in their own context.
Verify identity and access on the server
Review sign in, account recovery, session handling, role changes, and access to individual records. Check that the server confirms permission for every sensitive operation, including requests made directly to an API.
Test both permitted and denied actions. Hiding a page or button in the browser is not an access control rule; the server must reject requests that the current user is not allowed to make.
Follow data through the application
Trace important information from forms and APIs through validation, database queries, integrations, and rendered pages. Validate on the server, use safe query methods, and encode user supplied content appropriately when displaying it.
Check where credentials and sensitive values are stored, what the application records in logs, and what appears in errors. Keep secrets out of source code and avoid exposing private data in logs or public error messages.
Review the production environment and maintenance plan
Inspect production configuration, dependency updates, backups, restore procedures, monitoring, and who is responsible for responding to problems. Application security depends on how the system is deployed and maintained as well as on its source code.
Automated tools can help identify issues, but findings need to be checked against the application’s design and business rules. Document the review scope, confirmed findings, their impact, and practical remediation steps. A review can reduce known risks; it cannot promise that software will never be attacked.