Modern API Security & WAAP: Protecting the Hidden Doors of Your Digital Business

Introduction: APIs Are the New Front Door for Cyberattacks

Modern businesses depend on APIs (Application Programming Interfaces) to connect websites, mobile applications, payment gateways, customer management systems, cloud platforms, and third-party services. These connections make digital operations faster and more efficient, but they also create additional opportunities for cybercriminals.

Every API endpoint that exposes business data or functionality can become a potential entry point for attackers. A poorly secured endpoint could expose customer information, allow unauthorized transactions, reveal confidential records, or enable attackers to manipulate business processes without ever breaking through a traditional network firewall.

For organizations operating in Ghana and across the global digital economy, the risks are increasingly relevant. E-commerce platforms, fintech applications, government portals, educational platforms, and enterprise management systems all rely on APIs to deliver essential services.

The challenge is that protecting a website is no longer enough; organizations must understand and secure every API that supports it.

This is where modern API security and Web Application and API Protection (WAAP) become essential.

1. What Is WAAP, and Why Does It Matter?

Web Application and API Protection, commonly known as WAAP, is a security approach designed to protect web applications and APIs against malicious traffic, exploitation attempts, automated abuse, and other application-layer threats.

Traditional Web Application Firewalls (WAFs) primarily inspect HTTP and HTTPS traffic for suspicious patterns, known attack signatures, and policy violations. They remain valuable, but modern applications require broader protection.

A WAAP solution can combine several capabilities:

• Web Application Firewall: Detects and blocks common web attacks, including SQL injection and cross-site scripting.
• API discovery and protection: Identifies exposed endpoints and helps enforce API-specific security policies.
• Bot management: Detects automated abuse, scraping, credential stuffing, and suspicious request patterns.
• Distributed Denial-of-Service protection: Helps mitigate attacks intended to overwhelm applications and APIs.
• Behavioral analysis: Identifies unusual request patterns and activity that may indicate account abuse or data exfiltration.

The exact capabilities vary by provider and deployment. WAAP is not a substitute for secure application development, proper authorization, or sound identity management. It provides another layer of defense.

2. Why Traditional WAFs Can Miss Modern API Attacks

A traditional WAF is useful for identifying malicious traffic, but not every attack looks malicious at the HTTP level.

Consider an application that allows authenticated users to retrieve customer records through an endpoint such as:

GET /api/customers/1042

A WAF may see a normal HTTPS request containing a valid session token. The request may have no suspicious characters, malformed payloads, or recognizable attack signatures.

However, if the application does not verify whether the requesting user is authorized to access customer 1042, an attacker may change the identifier and retrieve another customer’s information.

This is an example of Broken Object Level Authorization (BOLA), a major category of API security vulnerability.

The request can be syntactically valid and authenticated while still being unauthorized.

Common API attacks that traditional filtering may miss

Broken Object Level Authorization (BOLA)

Attackers manipulate object identifiers to access records belonging to other users, customers, departments, or organizations.

Broken Function Level Authorization (BFLA)

An ordinary user accesses an administrative function because the application fails to enforce the correct permissions.

Business logic abuse

Attackers exploit legitimate application workflows, such as repeatedly claiming a promotion, manipulating order quantities, abusing refund processes, or submitting duplicate transactions.

GraphQL abuse

An improperly configured GraphQL endpoint may permit excessive query depth, expensive nested queries, unrestricted introspection, or unauthorized access to sensitive data.

Low-and-slow attacks

Instead of generating a sudden flood of requests, an attacker makes small numbers of carefully chosen requests over an extended period. Each request may appear normal, but the combined activity can reveal sensitive records or gradually abuse a business process.

How to strengthen API defenses

Organizations should combine traffic filtering with application-level controls:

1. Enforce authorization checks on every protected object and operation.
2. Validate input against explicit schemas and permitted values.
3. Apply per-user, per-token, and per-endpoint rate limits.
4. Restrict GraphQL query depth, complexity, and execution cost.
5. Monitor unusual access patterns and repeated attempts to enumerate records.
6. Log security-relevant events without exposing passwords, access tokens, or sensitive personal data.
7. Test authorization rules using different roles, accounts, and organizational boundaries.

The central principle is simple: a valid login does not automatically authorize every action.

3. Shadow APIs and Zombie APIs: The Hidden Attack Surface

Organizations frequently maintain more APIs than their security teams realize.

A development team might create a temporary endpoint for testing. A mobile application may continue using an older API version after the main website has been upgraded. A third-party integration may expose an endpoint that is not included in the organization’s security inventory.

Over time, these endpoints can become forgotten entry points into production systems.

What are shadow APIs?

Shadow APIs are endpoints that operate outside established API governance, documentation, or security oversight.

Examples include:

• Development or staging APIs accidentally exposed to the public internet.
• Undocumented endpoints created for internal applications.
• APIs deployed by individual teams without centralized security review.
• Administrative routes that were never intended for public access.

What are zombie APIs?

Zombie APIs are older or supposedly retired endpoints that remain operational after the organization believes they have been decommissioned.

For example, a business might launch /api/v2/payments while leaving /api/v1/payments accessible. If the older version lacks modern authentication, authorization, or transaction controls, attackers may target it instead of the newer endpoint.

How organizations can discover hidden APIs

API security begins with knowing what is actually running.

Maintain a centralized API inventory. Record each API’s owner, purpose, environment, authentication method, data classification, dependencies, and lifecycle status.

Inspect traffic and infrastructure. Use API gateways, reverse-proxy logs, cloud load balancer records, DNS information, and authorized security scanning to identify endpoints that are not documented.

Compare deployed endpoints with specifications. Where OpenAPI, Swagger, or other API definitions exist, compare them against observed production traffic and deployed routes.

Monitor for outdated versions. Identify endpoints that still receive traffic despite being marked for retirement.

Establish a retirement process. Decommission obsolete endpoints, revoke associated credentials, remove unused routes, and verify that the endpoints are no longer reachable.

Apply default-deny access policies. Unknown endpoints should not automatically inherit public access simply because they are deployed within an existing application.

Discovery must be performed through authorized systems and approved testing. Uncontrolled scanning can disrupt production services or violate third-party policies.

4. Securing Webhooks: Protecting Automated Business Transactions

Webhooks allow one application to notify another when an event occurs.

For example, a payment provider may notify an online store when a customer completes a payment. A payroll platform may send a notification when salaries have been processed. A customer management system may receive events from an external service when a new customer registers.

Webhooks eliminate the need for constant polling, but they also create a security challenge: how does the receiving application know that an incoming request genuinely came from the expected provider?

Without appropriate verification, an attacker may attempt to forge webhook requests, trigger unauthorized workflows, or manipulate payment and order statuses.

HMAC signature verification

Hash-based Message Authentication Code (HMAC) signatures allow a receiving application to verify that a webhook was generated by a party possessing the shared secret.

A secure implementation generally follows these steps:

1. The provider generates a signature using the webhook payload and a secret key.
2. The provider sends the payload and signature to the receiving endpoint.
3. The receiving application calculates its own signature using the same secret and the exact raw request body.
4. The application compares the expected signature with the received signature using a constant-time comparison function.
5. If verification fails, the request is rejected before it can trigger sensitive business operations.

The exact signing procedure depends on the provider. Some providers sign timestamps or additional request fields, so developers must follow the official integration documentation rather than inventing their own signature format.

Illustrative Python code for a provider that signs the raw body using HMAC-SHA256:

import hashlib
import hmac

def verify_signature(raw_body, supplied_signature, secret):
    expected = hmac.new(
        secret.encode("utf-8"),
        raw_body,
        hashlib.sha256
    ).hexdigest()

    return hmac.compare_digest(
        expected,
        supplied_signature
    )

This example illustrates signature comparison only. A production implementation must also follow the provider’s exact signature encoding, securely manage secrets, handle timestamps or replay protection where supported, and reject malformed requests.

Never treat a successful signature check as a reason to skip business validation.

Preventing replay attacks

A captured valid webhook might be submitted repeatedly to trigger the same action multiple times.

Organizations should implement replay protection using provider-supported timestamps, unique event identifiers, idempotency controls, and event-processing records.

For example, if a payment provider sends the same successful-payment event three times, the system should not create three separate paid orders or credit a customer’s account three times.

Rate limiting and IP restrictions

Additional webhook defenses include:

• Apply rate limits appropriate to the provider’s legitimate traffic.
• Restrict source IP addresses where the provider publishes reliable ranges and the network architecture supports enforcement.
• Keep IP allowlists updated when provider ranges change.
• Use HTTPS and restrict webhook endpoints to the required HTTP methods.
• Reject malformed or unexpectedly large payloads.
• Record event IDs and processing outcomes for investigation.

IP whitelisting should be treated as a supplementary measure, not a replacement for cryptographic verification. Requests can originate through changing infrastructure, proxies, or compromised networks, and IP addresses alone do not establish authenticity.

Payment webhook example

Imagine an online store receives a request claiming that an order worth GHS 2,500 has been paid.

A secure system should not mark the order as paid merely because the incoming JSON contains "status": "success".

Instead, it should:

1. Verify the webhook according to the payment provider’s official signing procedure.
2. Confirm the event is valid and has not already been processed.
3. Verify the transaction reference and relevant order details.
4. Confirm the amount and currency match the expected transaction.
5. Confirm the transaction belongs to the correct merchant and order.
6. Use the provider’s server-side verification API where appropriate to independently confirm the transaction.
7. Update the order through an atomic, idempotent operation.
8. Record the outcome for reconciliation and auditing.

For payment integrations, these checks can prevent fraudulent order fulfillment, duplicate credits, and inconsistencies between payment records and business accounts.

5. API Security for REST and GraphQL Applications

REST and GraphQL both require strong security controls, but their designs create different operational considerations.

Security area	REST APIs	GraphQL APIs
Endpoint management	Multiple resource routes	Often a single main endpoint
Authorization	Check each resource and operation	Check each resolver, object, and operation
Abuse prevention	Apply endpoint and identity-based limits	Also restrict query depth and complexity
Input validation	Validate parameters and request bodies	Validate variables, arguments, and nested inputs
Monitoring	Track route-level activity	Track query patterns and expensive operations

A single GraphQL endpoint can expose a large amount of application functionality. Protecting only the endpoint URL is therefore insufficient. Security must extend to the underlying resolvers, data access rules, and execution limits.

For REST, organizations should also avoid assuming that unpredictable identifiers or UUIDs eliminate authorization risks. An identifier may be difficult to guess, but the server must still verify access rights.

6. Building a Practical API Security Strategy

Effective API security requires coordinated action across development, infrastructure, operations, and management.

A recommended security framework

Layer 1: Discover

Build and maintain an inventory of production APIs, third-party integrations, versions, and exposed endpoints.

Layer 2: Authenticate

Use strong identity controls, securely managed credentials, appropriate OAuth 2.0 or OpenID Connect flows, and short-lived tokens where suitable.

Layer 3: Authorize

Enforce least privilege and verify user, service, tenant, object, and function permissions on the server.

Layer 4: Validate

Apply schema validation, payload limits, strict content-type handling, and safe error responses.

Layer 5: Protect traffic

Use an API gateway or WAAP solution to enforce suitable traffic policies, bot defenses, rate limits, and attack detection.

Layer 6: Secure integrations

Verify webhook signatures, implement replay protection, secure secrets, and validate transactions before processing them.

Layer 7: Monitor and respond

Centralize relevant logs, establish alerts for unusual access patterns, investigate suspected data exfiltration, and maintain an incident response procedure.

Layer 8: Test continuously

Integrate API security testing into development and release processes. Review authorization rules, dependencies, configurations, and retired endpoints regularly.

No single product provides complete protection. The strongest approach combines secure architecture, disciplined development, effective monitoring, and carefully configured security technology.

7. What Ghanaian Businesses and Public Institutions Should Prioritize

As more organizations digitize payments, citizen services, school administration, customer management, payroll, and internal operations, API security becomes a business continuity and data protection concern.

Organizations should begin with practical steps:

• Inventory public-facing APIs and third-party integrations.
• Review authentication and authorization on endpoints that expose personal, financial, payroll, or government data.
• Verify payment callbacks and webhooks before updating financial or order records.
• Remove obsolete API versions and restrict development environments.
• Introduce appropriate rate limits and monitoring.
• Review third-party plugins, mobile applications, and integrations that communicate with production systems.
• Establish clear responsibility for API ownership, maintenance, and incident response.

Public institutions and businesses handling personal data should also consider their applicable legal and regulatory obligations, including relevant requirements under Ghana’s Data Protection Act, 2012 (Act 843), and sector-specific rules where applicable.

Security requirements vary by organization and service. Technical controls should be supported by documented policies, staff training, periodic assessments, and accountable system ownership.

Conclusion: Secure Every API, Not Just the Website

APIs are essential to modern digital business, but every exposed endpoint expands the potential attack surface. Traditional firewalls remain useful, yet they cannot independently prevent authorization abuse, business logic manipulation, forgotten endpoints, or fraudulent webhook processing.

Modern API security requires organizations to know what they expose, control who can perform each action, validate every sensitive transaction, and continuously monitor how their systems behave.

WAAP technology can strengthen these defenses, but the real foundation is a security-first development process supported by strong authorization, API discovery, cryptographic verification, and continuous testing.

The key question for every organization is no longer simply whether its website is protected. It is whether every API connected to that website can be trusted.

Strengthen Your Digital Infrastructure with Sikaba Systems

At Sikaba Systems, we focus on digital solutions that help businesses, churches, and public institutions manage their operations more effectively.

From custom web applications and business management systems to secure integrations and digital infrastructure, building reliable systems begins with understanding the processes, data, and security requirements behind them.

Visit https://sikabasystems.com/ to explore our digital solutions and discover how better-designed systems can support your organization’s digital transformation.