Thousands Of Publicly Exposed API Tokens Could Threaten Software Integrity

JFrog’s discovery underscores the urgent need for more API governance. Whether in public-facing source code repositories or mobile application manifests, improper exposure of privileged API Tokens compares to leaving your house keys on a hook outside your locked front door. Sometimes this occurs in error when a developer uses an API key in development but forgets to remove it from the code before it gets checked in. Other times, it stems from plain bad application design and security practices, where API credentials have not been stored and utilized properly. Once an active API credential gets into the wrong hands, an attacker will use the credential to exercise the API. This typically includes reconnaissance to determine the capabilities of the API, the type of data and functions it has access to, and whether the APIs are susceptible to business logic attacks. From here, depending on the function of the API, an attacker may be able to exfiltrate confidential information or get access to system functions that can be used to disrupt operation of a service. Detecting API abuse by an attacker that has live privileged credentials presents challenges for a lot of organizations. Many organizations don’t employ adequate API runtime protection to detect nefarious activities against an API. API Gateways and traditional WAF technologies cannot detect many of the API attack and abuse patterns we see today, especially when the attacker purposely stays low and slow in their activity to evade rate limit and ddos detections. To provide immediate visibility and protection, proper contextual behaviour-based API runtime protection technology should be employed to detect and prevent any malicious behaviours against production APIs. Additionally, organizations should avoid using non-expiring static API tokens, and leverage more secure authentication and authorization methods such as OIDC or OAuth.