Authentication in APIs is a little tricky and difficult to develop, so during the initial development phase and for the sake of simplicity developers try to not implement authentication and authorization processes. As the application keeps growing, they will add these recommendations to existing code and during this transition they may have left some of the old internal APIs without authentication. Hackers will try to find these kinds of poorly authenticated flaws to bypass the login validation and gain access to their application data. According to Okta, most of the data breaches in 2020 fall under this category and so this is one of the most preferred approaches to attackers.
Authentication is said to be broken if hackers are able to compromise passwords, keys, session tokens and user account information. As per OWASP, APIs may fall under this category if
API doesn’t have authentication validation
API permits credential stuffing
API permits attackers to perform a brute force attack without presenting captcha/account lockout mechanism
Permits weak passwords
Sends sensitive authentication details, such as auth tokens and passwords in the URL
Strong password policy not implemented
Below are some of the preventive measures which are to be followed to protect application from these kinds of exploits:
Authentication support for all API’s
Authorization design developed in a good and structured way using access controls
Session tokens need to be expired in shorter time
Rate limiting and account locking after specific invalid logins
Rotation of keys and certs
Internal APIs should be audited and not exposed to outside
Multi factor authentication support for critical APIs
Enforcing strong password policy with special chars, capitals, numbers and minimum of 8 characters length
