Forrester’s Three-Pillar Model for API Enablement Explained

The API enablement model described by analyst firm Forrester rests on three pillars. Whatever labels are used, the idea is that a successful programme needs strategy, delivery and protection working together. For security teams the model is a useful checklist, because APIs have become one of the most targeted parts of modern applications.

Pillar one: strategy

Decide which business capabilities you will expose, to whom and why. Without this, organisations end up with hundreds of unowned endpoints created by different teams, each with its own conventions. A clear strategy defines the audience, whether partners, customers or internal developers, and assigns an owner to every API so someone is accountable for its quality and security.

Pillar two: delivery

Standardise how interfaces are designed, documented and tested. Use a common specification format, naming conventions and versioning rules so developers know what to expect. A central catalogue lets teams find existing services instead of creating duplicates, and automated tests in the delivery pipeline catch breaking changes early.

Pillar three: protection

APIs expose data directly, so they need strong authentication, authorisation checks on every request, rate limiting and thorough logging. Broken object-level authorisation, where one user can read another record by changing an identifier, is the most common serious flaw. Add input validation, encryption in transit and an API gateway that enforces policy consistently.

Using the model as a checklist

Ask of each API: who owns it, is it documented, is it tested, and is it protected? If any answer is no, the programme will eventually stall or leak. Review the answers every quarter and track simple measures such as the number of undocumented endpoints and the time to fix findings.

Common pitfalls

Teams often treat security as the last step, publish internal APIs without authentication because they feel safe, or forget old versions that remain online. Include shadow APIs in discovery scans and retire old versions on a schedule.

Key takeaways

• Pillar one: strategy: Decide which business capabilities you will expose, to whom and why. Without this, organisations end up with hundreds of unowned endpoints created by different teams, each with its own conventions.
• Pillar two: delivery: Standardise how interfaces are designed, documented and tested. Use a common specification format, naming conventions and versioning rules so developers know what to expect.
• Pillar three: protection: APIs expose data directly, so they need strong authentication, authorisation checks on every request, rate limiting and thorough logging. Broken object-level authorisation, where one user can read another record by changing an identifier, is the most common serious flaw.
• Using the model as a checklist: Ask of each API: who owns it, is it documented, is it tested, and is it protected? If any answer is no, the programme will eventually stall or leak.
• Common pitfalls: Teams often treat security as the last step, publish internal APIs without authentication because they feel safe, or forget old versions that remain online. Include shadow APIs in discovery scans and retire old versions on a schedule.

Frequently asked questions

Do small teams need an API gateway?

Often yes. It gives one place to apply authentication, rate limits and logging.

What is the biggest API risk?

Missing authorisation checks, which let users access data that is not theirs.

Final thoughts

Strategy, delivery and protection support one another. Use the three pillars as a simple review framework and your API programme will be more reliable and safer.