SECURE · Application & API Security
Protect the Applications and APIs Your Customers Rely On.
We secure web, mobile and API estates through design review, vulnerability management and runtime protection.
- Fewer exploitable application flaws
- Protected customer-facing APIs
- Faster remediation
- 1Discover and Classify
- 2Model Abuse Cases
- 3Test and Triage
- 4Enforce Runtime Controls
- 5Verify and Track
Executive Summary
- 01API compromise often exploits missing authorization checks and forgotten endpoints rather than exotic techniques.
- 02Threat modeling and pipeline testing find design and logic flaws while they are still cheap to correct.
- 03Runtime controls reduce exposure between discovery of a flaw and its fix, but they never replace the fix.
The Challenge
Digital services expose more APIs every year, and API abuse is now a common route to fraud and data exposure.
Vulnerabilities found late in development are expensive to fix and often ship anyway.
The DAAKYI Approach
DAAKYI reviews application and API designs, embeds vulnerability management into release cycles and implements protection for exposed services.
Findings flow to developers with clear remediation guidance.
- 01
Application threat modelling
- 02
API inventory and security controls
- 03
Application vulnerability management
- 04
Runtime protection
In Depth
How the Discipline Works
Start with What Is Actually Exposed
Most organizations cannot list every API they run. Mobile apps call endpoints that web teams forgot, partners use versions that were meant to be retired, and test environments sit on the public internet. Security work begins by building an inventory from gateway logs, code repositories, cloud configuration and traffic analysis. Each endpoint is tagged with an owner, a data classification and an authentication method. Without this record, controls are applied unevenly and shadow APIs become the easiest way in. The inventory is not a one-time list. It must update whenever a release changes the attack surface.
Model Threats Before Code Ships
Threat modeling asks how a feature could be abused, not only how it should be used. Teams draw data flows, mark trust boundaries and list attacker goals such as account takeover, scraping, or manipulating a payment amount. The output is a short set of abuse cases with matching controls and test conditions. Business logic flaws are the main target here, because scanners rarely detect them. A transfer endpoint that accepts a negative value or skips an ownership check passes every automated test. Modeling catches these gaps while a fix still costs a design change rather than a rewrite.
Protect, Verify and Close Findings
Protection works in layers. Code fixes remove the flaw. Gateways enforce authentication, schema validation and rate limits. A web application firewall or API protection layer blocks known attack patterns and flags abnormal behavior at runtime. Verification then confirms each control works: retesting fixed issues, running dynamic and dependency scans in the pipeline, and sampling production traffic for abuse. A finding is closed only when evidence shows the fix holds. Severity should reflect exploitability and data exposure, not just a scanner score, so developers address the most dangerous issues first.
An API you have not inventoried is an API you cannot protect, test or explain to a regulator.
Capability Matrix
What the Service Includes
| Capability | Coverage | GUIDE | SECURE | OPERATE | Delivered Through |
|---|---|---|---|---|---|
| API Security | Discovery, authentication and abuse protection. | – | SECURE stage | – | Project Implementation |
| Vulnerability Management | Findings tracked to closure. | – | SECURE stage | – | Project Implementation |
| Secure Design Review | Threat models for new features. | – | SECURE stage | – | Project Implementation |
| Application Protection | Runtime controls for exposed services. | – | SECURE stage | – | Project Implementation |
API Security
Discovery, authentication and abuse protection.
- Stage
- SECURE
- Delivered Through
- Project Implementation
Vulnerability Management
Findings tracked to closure.
- Stage
- SECURE
- Delivered Through
- Project Implementation
Secure Design Review
Threat models for new features.
- Stage
- SECURE
- Delivered Through
- Project Implementation
Application Protection
Runtime controls for exposed services.
- Stage
- SECURE
- Delivered Through
- Project Implementation
How It Works
How Application & API Security Works
- 01Inventory
- 02Model Threats
- 03Protect
- 04Verify
Methodology
The Method, Step by Step
- 1
Discover and Classify
Build the inventory of web, mobile and API assets from gateway logs, repositories and cloud configuration. Record owners, environments, data types and authentication methods. Flag undocumented, deprecated and internet-exposed endpoints. This baseline decides where testing and protection effort goes first, and it is refreshed whenever new services are released.
- 2
Model Abuse Cases
Map data flows and trust boundaries for each high-risk feature. List how an attacker could abuse login, payment, onboarding and data export functions. Convert each abuse case into a required control and a test. Keep the model with the feature so developers update it when requirements change rather than filing it away.
- 3
Test and Triage
Combine static analysis, dependency checks, dynamic scanning and manual testing of business logic. Remove duplicates, confirm exploitability and rank findings by real impact. Each finding states the affected endpoint, a reproduction path and a specific fix. Developers receive tickets in their own tracker, not a separate report they must interpret.
- 4
Enforce Runtime Controls
Apply authentication, authorization checks, schema validation, rate limiting and bot controls at the gateway or protection layer. Tune rules against real traffic to limit false blocks. Use virtual patching to shield a vulnerable endpoint while the code fix is built, and log blocked requests for investigation.
- 5
Verify and Track
Retest every fix and confirm the control behaves as designed under attack conditions. Track findings to closure with owner, due date and evidence. Report aging and recurrence by team and flaw class, so repeated mistakes lead to training, secure libraries or pipeline gates instead of repeated tickets.
Operating Model
Delivered from the SECURE Pillar
Pillar position
SECURE
Engineering, Architecture & Implementation
Engagement model
Project Implementation
Design and deployment of security technologies.
Best for · Modernization and transformation
Threat Scenarios
What It Looks Like in Practice
Object ID Enumeration
How It Shows Up
One account sends thousands of sequential requests for different customer record IDs, and most succeed.
Response
Add server-side ownership checks, alert on enumeration patterns and throttle the offending client at the gateway.
Credential Stuffing on Login APIs
How It Shows Up
Login failures spike from many addresses, each sending few attempts, and some succeed using reused passwords.
Response
Combine per-account and per-device limits, bot detection and breached-password checks, with step-up authentication on risky sessions.
Forgotten Legacy API Version
How It Shows Up
An old API version still answers requests without the validation added to the current one.
Response
Inventory exposes it, owners retire or retrofit it, and the gateway blocks undocumented routes.
Vulnerable Third‑Party Library
How It Shows Up
A dependency scan flags a critical flaw in a library used across several services.
Response
Triage identifies exposed services, virtual patching shields them, and teams upgrade the library and retest.
| Scenario | How It Shows Up | Response |
|---|---|---|
| Object ID Enumeration | One account sends thousands of sequential requests for different customer record IDs, and most succeed. | Add server-side ownership checks, alert on enumeration patterns and throttle the offending client at the gateway. |
| Credential Stuffing on Login APIs | Login failures spike from many addresses, each sending few attempts, and some succeed using reused passwords. | Combine per-account and per-device limits, bot detection and breached-password checks, with step-up authentication on risky sessions. |
| Forgotten Legacy API Version | An old API version still answers requests without the validation added to the current one. | Inventory exposes it, owners retire or retrofit it, and the gateway blocks undocumented routes. |
| Vulnerable Third‑Party Library | A dependency scan flags a critical flaw in a library used across several services. | Triage identifies exposed services, virtual patching shields them, and teams upgrade the library and retest. |
Outcomes
What Your Institution Gains
- Fewer exploitable application flaws
- Protected customer-facing APIs
- Faster remediation
Deliverables and Roles
What You Receive, and Who Does What
| Deliverable | Purpose |
|---|---|
| API and Application Inventory | Gives a current, owned record of every exposed service and the data it handles. |
| Threat Models and Abuse Cases | Document how each high-risk feature could be attacked and which controls prevent it. |
| Prioritized Findings Register | Tracks each flaw with severity, owner, fix guidance and closure evidence. |
| Runtime Protection Baseline | Records gateway and firewall rules, rate limits and exceptions for audit. |
| Retest and Verification Report | Proves that fixes hold and controls behave as designed. |
| Role | Responsibility |
|---|---|
| Product or API Owner (Client) | Accepts risk decisions and ensures fixes are scheduled alongside the feature backlog. |
| Development Lead (Client) | Implements fixes, maintains threat models and keeps pipeline security gates working. |
| Application Security Engineer (Provider) | Performs design review and testing, triages findings and advises on remediation. |
| Security Operations Analyst (Client or Provider) | Monitors protection-layer alerts and investigates suspected API abuse. |
Maturity Model
Where Organizations Typically Stand
Stage 1
Reactive
Testing happens before major launches or after incidents. APIs are not inventoried and findings sit in static reports.
Stage 2
Managed
An inventory exists and scans run regularly. Findings reach developer trackers with owners and due dates.
Stage 3
Integrated
Threat modeling and automated tests sit in the pipeline. Gateways enforce schemas and authentication consistently.
Stage 4
Adaptive
Production telemetry feeds back into design. Recurring flaw classes drive secure libraries, training and policy-as-code.
Frameworks and Regulation
The Standards That Shape This Work
OWASP Top 10, API Security Top 10 and ASVS
The Top 10 lists are common risk categories for web applications and APIs. ASVS provides verifiable requirements that can serve as acceptance criteria for testing.
PCI DSS v4.0
It applies wherever applications handle cardholder data. The current revision is version 4.0.1, and the requirements that were future-dated became mandatory on March 31, 2025.
ISO/IEC 27001:2022
Annex A has 93 controls in four themes. The technological controls cover secure development and application protection, with ISO/IEC 27002:2022 giving guidance.
Ghana Data Protection Act, 2012 (Act 843)
Data security safeguards is one of its eight privacy principles. APIs that expose personal data fall under that expectation.
Buyer Guidance
Choosing the Right Provider
What to look for
- Look for manual testing of business logic, not just scanner output.
- Look for remediation guidance written for developers, with code-level examples.
- Look for mobile clients and the APIs behind them covered together.
- Look for retesting and closure tracking included in the scope.
Questions to ask a provider
- How do you discover APIs we do not know about?
- How do you test authorization across different user roles?
- How are findings delivered into our development tracker?
- How do you tune runtime rules so legitimate customers are not blocked?
Regulatory & Industry Context
The Obligations This Service Supports
Controls support PCI DSS, ISO/IEC 27001 secure development requirements and data protection law where personal data is processed.
Frameworks DAAKYI helps clients implement
- PCI DSS
- ISO/IEC 27001
- Ghana Act 843
- GDPR
Framework references describe client implementation support, not DAAKYI certifications.
Technical Detail
For Architects and Security Leads
Framework and regulatory alignment
- PCI DSS
- ISO/IEC 27001
- Ghana Act 843
- GDPR
Controls support PCI DSS, ISO/IEC 27001 secure development requirements and data protection law where personal data is processed.
Architecture reference
How Application & API Security Works: Inventory → Model Threats → Protect → Verify.
DAAKYI reviews application and API designs, embeds vulnerability management into release cycles and implements protection for exposed services.
Broken Object-Level Authorization in APIs
Broken object-level authorization occurs when an API accepts an object identifier from the client and returns the record without checking that the caller owns it. An attacker changes an account number in the path, then iterates through values. Sequential identifiers make this trivial; random identifiers only slow it down. The fix is a server-side ownership check on every request, applied centrally in middleware or policy code rather than endpoint by endpoint. Testing needs two authenticated test users, so one user's token is tried against the other's objects. Automated scanners seldom do this. Related risks include broken function-level authorization, where a regular user reaches administrative endpoints, and excessive data exposure, where responses return fields the client never displays.
Pipeline Controls and Token Handling
Pipeline controls move detection earlier. Static analysis runs on each pull request, dependency scanning flags vulnerable libraries, and secret scanning blocks committed credentials. Dynamic tests run against a staging build using the API's OpenAPI specification, which also lets a gateway reject requests that do not match the schema. Token handling needs equal care. Access tokens should be short-lived, scoped to the minimum permissions and validated for signature, issuer, audience and expiry on every call. Refresh tokens need rotation and revocation. Rate limits should apply per user, per client and per IP, because credential stuffing and scraping often spread requests across many addresses.
Glossary
Key Terms
- BOLA
- Broken object-level authorization, where an API returns an object without verifying that the caller may access it.
- Shadow API
- An API running in production that the security team does not know about or track.
- Virtual Patching
- A protection rule that blocks exploitation of a known flaw before the code is fixed.
- Schema Validation
- Rejecting requests whose structure, types or values do not match the API specification.
Related
Explore Connected Capabilities
Related services
Solutions
Platforms
Proof Points
What We Can Stand Behind
- Every stage of DAAKYI's delivery methodology produces documented, auditable deliverables.
FAQ
Questions Leaders Ask
DAAKYI Intelligence
Ask Kasara About Application & API Security
Kasara, our AI assistant, answers from DAAKYI's published content and can connect you with a specialist.
Next Step
Discuss Application & API Security with DAAKYI
Tell us about your environment and obligations. A DAAKYI specialist for Application & API Security will respond.
Talk to a Cybersecurity Expert