Most API technologists consider API security a topic addressed primarily at the WAF + API Gateway layer (the perimeter). While the perimeter is crucial, focusing only on that layer overlooks vital security measures that can significantly strengthen your defenses. In this post, I’ll dive into three critical practices that can elevate security deeper in your stack: scoped access for services, passing credentials by reference, and business logic validation.
Scoped access for services
One key tenet of API security is the principle of least privilege: services should only be able to invoke the API operations they need. However, in large enterprise systems, this can be difficult to enforce.
Conventionally, developers try to request the minimum set of scopes when acquiring tokens. Yet, there are several challenges with this approach:
- Some enterprise systems don’t support scoped tokens or token-based authorization mechanisms.
- Token scopes, often defined by third-party vendors or service owners, are frequently too broad to enforce true least-privilege access.
- Under tight deadlines, developers may need more time or knowledge to research the most restrictive scopes required for their use case.
- The process for obtaining access to enterprise systems is often tedious, leading developers to request broader permissions than necessary upfront. Rarely do they go back to reduce access later.
At Poly, we designed our service with these realities in mind, leveraging our Environments concept to deliver a security advantage. Environments in Poly serve multiple purposes:
- They map to lifecycle stages such as Dev -> QA -> Prod.
- They control developer access to different sets of services.
- Most importantly, they provide a way to scope access to a subset of API operations, or API Functions, on a per-project basis.
This allows implementers to offer only the most minimal subset of functions to clients consuming backend enterprise applications. API operations that are not needed will remain invisible, with their endpoints hidden. Even if someone were to identify an endpoint, using a key from an environment that does not include the API function will result in a 404 response.
By scoping function access on a project basis, enterprises can ensure that even if a client somehow acquires a token or secret, they cannot invoke unauthorized API operations.
Credentials by Reference
A second crucial security measure is tokenizing credentials to prevent raw credentials from being passed over the network. Tokenization ensures that access to a service is limited to a specific time and scope. However, there’s still the challenge of obtaining the token in the first place, which requires the service to possess the original credentials, at least temporarily.
Even when using vault patterns to externalize and encrypt credentials at rest, services must still handle the credentials during the token acquisition process. This introduces the risk that developers or DevOps engineers might inadvertently log or leak those credentials, despite efforts to secure them.
At Poly, we took this further by implementing credentials by reference. Instead of passing credentials directly, our system injects credentials at runtime via an inject statement in the Poly function call. When this happens, our outbound API Gateway retrieves and injects the credentials from a server-side secure vault without the service handling the credentials directly.
This means that services can use credentials securely without ever possessing or managing them at runtime. By decoupling the right to manage credentials from the right to use them, Poly ensures that an attacker can only invoke the allowed functions in that environment even if a service is compromised. They won’t gain access to the more powerful underlying credentials that could provide access to broader business applications.
Business Logic Validation
The third essential security measure at the service layer is business logic validation. Beyond the standard practices of validating inputs and tracking usage, service implementations should take a strong stance on detecting potential abuse or fraud based on the unique behavior of the service. This form of validation ensures that business rules and expectations are upheld, blocking or flagging suspicious actions. Since business logic varies widely across domains, there’s no one-size-fits-all solution.
For example, a service might flag a user who signs up for a gaming platform and purchases a large number of credits before even playing a single game. In such cases, the logic may either block the request entirely or trigger an alert for further investigation. Implementing this type of validation often involves orchestration that checks usage history and maintains allow/block lists or other contextual rules.
Poly sets itself apart through its flexible API orchestration capabilities. Unlike other approaches where you may be limited to vendor-supplied message processors, Poly allows you to leverage the full expressive power of code to implement tailored business logic. This flexibility is key because business validation logic is inherently domain-specific and tied to individual business practices. No middleware solution can offer pre-built processors that meet the unique needs of every enterprise.
I recommend using AI to assist in developing this kind of validation code. By providing AI with your core business flow, you can prompt it to enhance the logic with rules designed to detect and combat malicious behavior. Additionally, it’s an excellent practice to externalize this validation logic into a separate server or client function with a simple pass/fail interface. This approach ensures that the logic can evolve independently without needing to modify or expose the source code of your primary business service.
Each security measure—scoped access, credentials by reference, and business logic validation—can be implemented in any service architecture to enhance security at the service layer significantly. At Poly, we’ve embraced these principles and made them an integral part of our platform, simplifying their use for developing and managing enterprise integrations, microservices, and orchestrations.
If you’d like to explore how Poly can help streamline these processes for your business, feel free to reach out at hello@polyapi.io. We’d love to hear from you!
