Without a shadow of doubt, there are shadows in your API attack surface!

Happy New Year!

Last November, I had the privilege to share some tips on avoiding API abuses in Akamai’s Tokyo Tech Day:

One question I often heard from the curious audience is whether I can give some real world examples of shadow API or even shadow API parameters. Are they real threats or are they imaginary devices conjured up by security vendors?

Without a shadow of doubt, the following anonymized screenshot proves shadow API’s risk in the field:

This is a graphQL API for generating the OTP for end user login purposes. When I presented this to the concerned development team, they were greatly disturbed to see otpDigit is actually one of the tunable parameter. You can almost guess the attacker’s next step would be to reduce the value of otpDigit from the default 6 to just 1, drastically reducing the OTP combinations from a million to merely 10.

What’s the definition of shadow API or shadow API parameters? A practical definition would be any API endpoints / API parameters that is not under the spotlight, the part of your system that have been living under the shadow, at the edge of your security team’s conscious awareness.

Your API cyber-defence will be off to a great start in 2024 by digging out all the shadow API endpoints and parameters, and putting them under your security team’s spotlights. After all, you can’t defend APIs if you didn’t know about their existence in the first place. Akamai is here to help you be successful in this goal with our suite of security services and products, including