Application Security Services

Threat modelling is a structured process for identifying security requirements and potential vulnerabilities during the design phase before code is written. It answers four questions: what are we building (architecture and data flow diagram), what can go wrong (threat enumeration using STRIDE or PASTA methodology), what will we do about it (countermeasures for each identified threat), and did we do a good job (verification that countermeasures are actually implemented). Threat modelling before development is the most cost-effective security activity: a threat identified in design can be addressed by a design decision (which costs nothing to implement) or a few lines of code. The same threat discovered in production requires patching deployed code, testing, re-deploying, and potentially notifying affected customers. Microsoft's research found that fixing a security issue in design costs 1x; fixing it in code costs 6x; fixing it post-deployment costs 100x.

Authentication answers "who are you?" it verifies the identity of the user (username/password, OAuth token, certificate). Authorisation answers "what are you allowed to do?" it determines whether the authenticated user has permission to perform a specific action on a specific resource. The most common application security vulnerability is broken authorisation specifically Insecure Direct Object Reference (IDOR): after authentication, a user accesses `/api/orders/1234` (an order that belongs to another user) by simply modifying the ID in the URL. The application verified who the user was (authentication) but failed to verify that the user owns order 1234 (authorisation). Every data-modifying API endpoint must verify both: that the request is authenticated (valid session or token) AND that the authenticated user has permission to perform this action on this specific resource (authorisation check at the resource level, not just the route level). Row-Level Security in PostgreSQL enforces authorisation at the database level a bug in application authorisation logic cannot return another user's data if RLS policies are configured correctly.