OWASP Serverless Top 10 #2: Broken Authentication
Serverless applications are comprised of hundreds of different functions that run separately, triggered from a different event and with no notion of the other moving parts. Attackers will try to look for a forgotten resource, like a public cloud storage, or open APIs. However, external-facing resources should not be the only concern.
For example, functions triggered by organizational emails could be be triggered by attackers sending spoofed emails. Attackers could then execute internal functionality without any authentication.
Security Weakness and Impact
Broken authentication is usually a result of poor design of identity and access controls. In serverless architectures, with multiple potential entry points, services, events, and triggers and no continuous flow, things can get even more complex. On the plus side, brute-force and default passwords are less likely to be an issue when using the authentication services provided by the infrastructure.
Having access to functions without authentication can lead to sensitive data leakage, but could potentially also lead to breaking the system’s business logic and flow of execution.
How to Prevent
- Different types of identity and access controls require different types of authentication, depending on the type of access required. If possible, use the available solutions provided by the infrastructure.
- External-facing resources should require authentication and access control according to the service provider’s best practices:
- For service authentication between internal resources, use known secure methods, such as Federated Identity (e.g. SAML, OAuth2, Security Tokens) and make sure to follow security best practices (e.g. encrypted channels, password and key management, client certificate, OTA/2FA).