The proliferation of always-on, web available applications has created a new universe of products, services, tools, entertainment, and, of course vulnerability. Once protected by the safe confines of fire walls and enterprise networks, cloud based apps (SaaS) are today, by the very nature of their purpose, exposed to unprecedented threats.
As seen below, it isn’t just user data at risk. Here we offer a few fundamental considerations to accompany the inventive process in order to safe-guard the application, its environment, and the ever-sacrosanct data therein.
- Authentication: All APIs, with as few exceptions as possible, should be authenticated. Examples of unauthenticated APIs can be the login & password reset APIs, which, by definition, will be unauthenticated. Using Single Sign On (Google, LinkedIn) instead of your own user database makes things convenient for the users. Authentication must be token based, which should expire after a period.
- Authorization: All APIs should have an authorization layer. This layer defines which user (role) is allowed to access which resources in the system. Eg, adding new users to the system can be a privilege limited only to the admin roles of the system. Authorization caches can be used to boost the performance of the app, as authorization checks are repeated for every API call.
- Auditing: tools like splunk should be used whenever possible. This allows real-time monitoring for anomalous activities. This implies that logging must be fine grained.
- Static Code Analysis: tools like checkmarx should be used whenever possible to identify & fix vulnerabilities in code.
- Common Vulnerabilities & Exposures (CVEs): maintain a list of all 3rd party code used in the app, & keep an eye on their CVEs. CVEs are public disclosures of vulnerabilities & exposures in software modules. If any CVE affects the app, alternatives or other mitigation & contingency measures must be found to minimize the impact of the disclosed vulnerabilities. This monitoring should be done for the lifetime of the app.
- Data Protection: certain sensitive data – like personally identifiable information, or financial data – should be stored encrypted in the database, if at all. One of the best ways is to have a separate key management server, which dynamically issues decryption keys to each authenticated requester, when accessing encrypted data.
- Randomized URLs: when allowing access to unauthenticated or unauthorized user-specific resources, like images – use long, randomized URLs so that others cannot guess related URLs.
- Rate Limiting: all APIs should be rate limited to ensure nobody can launch DoS/DDoS attacks, whether authenticated/authorized or not. For unauthenticated APIs, an exponential backoff is must. This ensures that attackers cannot hog/monopolize system resources while probing the system for vulnerabilities.
