5 Types of API Workflows and How to Secure Them

• Why API Workflow Visibility is Important for Security
• How Do API Workflows Work?
• Common Types of API Workflows and Security Considerations

• Key API Workflow Security Risks
• Best Practices for Effective and Secure API Workflows
• Securing API Workflows with Radware API Security Service

• Abuse of legitimate API functions: Attackers can misuse valid features such as account creation, password resets, or coupon redemption. Workflow visibility reveals excessive repetition, unusual ordering, and unexpected volumes.
• Benign-looking individual requests: A single request may appear normal, while thousands of similar requests can indicate scraping or data harvesting. Connecting related calls helps security teams detect these broader patterns.

• Business logic attacks across multiple calls: Attackers may skip verification, modify approved objects, or repeat transactions using otherwise valid requests. Workflow visibility helps identify violations of expected steps, dependencies, and state changes.
• Unknown paths through shadow APIs: Undocumented or forgotten endpoints can expose alternative workflow paths that bypass approved controls. Workflow visibility helps uncover these routes and their connections to sensitive data and downstream services.

1. A User or Application Initiates a Business Process

An API workflow begins when a user, application, or automated system triggers a business process. This might include placing an order, creating an account, requesting a payment, uploading a file, or updating customer information. The initial action determines which APIs and backend services need to participate in the workflow.

The trigger can come from a web interface, mobile app, scheduled job, webhook, or another service. In more complex systems, a single user action may start several connected processes that run across different applications.

2. The Client Sends a Request to an API Endpoint

The client sends an API request to the appropriate endpoint, usually over HTTP. The request can include parameters, headers, authentication credentials, and a request body containing the data needed for the operation. The endpoint identifies which function or resource the client wants to access.

For example, a client may send a POST request to create a new resource or a GET request to retrieve existing data. The API then parses the request and passes the relevant information to the service responsible for handling it.

3. The API Validates Authentication and Authorization

Before processing the request, the API checks whether the caller is authenticated and allowed to perform the requested action. Authentication may use API keys, tokens, certificates, or other credentials. Authorization then determines whether that identity has permission to access the requested resource or operation.

These checks are often performed at an API gateway, identity service, or within the application itself. The API may also validate token scopes, user roles, resource ownership, or other access rules before allowing the workflow to continue.

4. Multiple API Calls Execute in a Defined Sequence

Many business processes require more than one API call. For example, an ecommerce workflow may create an order, process payment, update inventory, and request shipment through separate APIs. These calls often need to occur in a specific order because later steps depend on data or state created earlier in the workflow.

The sequence may be controlled by application code, a workflow engine, or an orchestration service. Some steps run synchronously, while others may be handled asynchronously through queues or events when immediate completion is not required.

5. Backend Services Process Data and Business Logic

Each API call can trigger one or more backend services. These services may query databases, validate input, calculate values, enforce business rules, or communicate with external systems. The API acts as the interface, while the underlying services perform the actual processing required by the workflow.

For example, a payment API may call a fraud detection service before approving a transaction. A customer API may check several databases before deciding whether an account can be updated.

6. APIs Exchange Responses and State Between Steps

As each step completes, APIs return responses containing data, status information, identifiers, or errors. Later steps may use this information to continue the workflow. For example, an order ID created in one request may be passed to payment, inventory, and shipping APIs in subsequent requests.

State can also be stored in databases, caches, workflow engines, or message queues. Maintaining the correct state is important because later API calls need to know what has already happened and which actions are still allowed.

Once all required steps are complete, the workflow returns a final result to the user or calling application. This may be a confirmation message, updated record, transaction status, generated file, or error response. The final result reflects the combined outcome of all API calls and backend operations performed during the workflow.

If one step fails, the workflow may retry the operation, return a partial result, or reverse earlier changes. How failures are handled depends on the workflow design and whether the process needs strong consistency across all participating systems.

1. User Registration and Account Creation

A user registration workflow usually begins when a user submits information such as an email address, username, password, or profile details. The API validates the input, checks whether the account already exists, creates a new user record, and may trigger email or phone verification.

Additional API calls can assign default roles, create related profile records, or connect the account to other services. The workflow may also include fraud checks, consent collection, and audit logging before the account becomes active.

Security considerations:

• Validate and sanitize all user input to prevent injection attacks and malformed data from reaching backend systems.
• Hash passwords using a secure password hashing algorithm, such as Argon2id or bcrypt, before storing them.
• Apply rate limits and automated abuse detection to prevent mass account creation and registration endpoint abuse.
• Prevent account enumeration by avoiding responses that reveal whether a specific email address or username is already registered.
• Assign minimum required permissions to new accounts and verify email addresses before enabling sensitive operations.

2. Login and Authentication

A login workflow starts when a user submits credentials or uses an external identity provider. The authentication API verifies the credentials and, if successful, issues a session token, access token, or cookie that the client can use for later requests.

The workflow may also include multi-factor authentication, device checks, risk scoring, or token refresh operations. Each step must maintain the correct identity and session state so that later API calls can be authorized properly.

Security considerations:

• Enforce HTTPS for all authentication requests to protect credentials and tokens during transmission.
• Apply rate limiting and account-based protections to reduce brute-force attacks and credential stuffing.
• Use multi-factor authentication for sensitive accounts and high-risk login attempts.
• Store session tokens securely, use short expiration periods where appropriate, and rotate refresh tokens to reduce the impact of token theft.
• Validate token signatures, expiration times, issuers, and audiences before accepting authentication tokens.
• Protect cookie-based sessions against cross-site request forgery (CSRF) using appropriate cookie attributes and CSRF defenses.

3. Password Reset and Account Recovery

A password reset workflow typically begins when a user requests access to an account they can no longer log into. The API verifies that the account exists, creates a short-lived reset token or code, and sends it through an approved recovery channel such as email or SMS.

The user then submits the token with a new password. The API validates the token, updates the credential, invalidates old sessions or reset tokens, and may generate a security notification to confirm the change.

Security considerations:

• Use cryptographically secure, unpredictable reset tokens with short expiration times and single-use enforcement.
• Return consistent responses for existing and nonexistent accounts to prevent account enumeration.
• Apply rate limits to reset requests and token verification attempts to prevent abuse and token guessing.
• Store reset tokens securely, preferably as hashes, and avoid exposing them in application logs or analytics systems.
• Invalidate outstanding reset tokens and existing sessions after a successful password change.
• Avoid relying on easily compromised recovery methods, such as security questions, and require additional verification for high-risk recovery attempts.

4. eCommerce Checkout

An ecommerce checkout workflow can involve several APIs working together. The process may validate the shopping cart, calculate taxes and shipping costs, reserve inventory, process payment, create the order, and start fulfillment.

Because these steps depend on one another, the workflow must manage failures carefully. For example, if payment succeeds but inventory is unavailable, the system may need to issue a refund or cancel the order to keep the transaction consistent.

Security considerations:

• Recalculate prices, discounts, taxes, and shipping costs on the server rather than trusting values submitted by the client.
• Verify that users are authorized to access or modify the shopping carts, orders, and payment methods referenced in API requests.
• Use a trusted payment processor and avoid storing raw payment card data unless the system meets applicable PCI DSS requirements.
• Implement idempotency keys for payment and order creation requests to prevent duplicate charges during retries.
• Validate payment confirmation webhooks using signatures or other authentication mechanisms before updating order status.
• Protect checkout APIs against automated abuse, including card testing, coupon abuse, and inventory reservation attacks.
• Avoid exposing sensitive payment information or personal customer data in API responses and application logs.

Third-party API workflows connect an application to external services such as payment processors, shipping providers, identity platforms, CRM systems, or analytics tools. The application sends requests to the external API and uses the response to continue its own business process.

These workflows often depend on external authentication, rate limits, schemas, and availability. They may also use webhooks or callback endpoints so the third-party service can notify the application when an asynchronous task is complete.

Security considerations:

• Store API keys, access tokens, and other integration credentials in a secure secrets management system rather than embedding them in source code.

• Grant third-party integrations only the permissions and data access required for their specific operations.
• Validate webhook signatures, timestamps, and event identifiers to prevent forged requests and replay attacks.
• Validate external API responses before processing them, including data types, expected fields, and permitted values.
• Restrict outbound requests to approved destinations where possible to reduce server-side request forgery (SSRF) risks.
• Rotate integration credentials regularly and revoke them immediately when an integration is compromised or no longer needed.
• Minimize sensitive data shared with external services and avoid logging authentication credentials or confidential API responses.

Broken Object Level Authorization (BOLA)

BOLA occurs when an API does not properly verify whether a user is allowed to access a specific object. An attacker may change an object identifier in a request, such as a user ID, order ID, or document ID, to access another user’s data.

Impact: In a workflow, this weakness can affect several connected steps. If one API returns an unauthorized object, later calls may use that object to modify, delete, or expose additional information. This can lead to data breaches, unauthorized transactions, and account compromise.

Mitigations:

• Enforce object-level authorization on every request: Verify that the authenticated user has permission to access or modify the requested object, regardless of previous workflow steps.
• Validate permissions using server-side context: Base authorization decisions on authenticated identities, roles, and ownership relationships rather than client-supplied object identifiers.
• Test authorization across workflow steps: Include negative tests that attempt to access, modify, or delete objects belonging to other users at different stages of the workflow.

Broken Function Level Authorization

Broken function level authorization occurs when an API allows users to call functions that should be restricted to certain roles or permission levels. For example, a standard user may be able to access an administrative endpoint by sending a direct request.

Impact: This risk becomes more serious when privileged functions are part of a larger workflow. An attacker may combine authorized and unauthorized actions to change account settings, approve transactions, or perform other restricted operations. This can result in privilege escalation, unauthorized system changes, and financial losses.

Mitigations:

• Enforce server-side function-level authorization: Check permissions for every API endpoint and operation, including administrative and sensitive functions.
• Implement role-based or attribute-based access controls: Use RBAC or ABAC policies to restrict operations based on user roles, permissions, resource attributes, and request context.
• Test for privilege escalation paths: Verify that users cannot access restricted functions through direct requests, alternative endpoints, modified HTTP methods, or unexpected workflow sequences.

Authentication and Session Abuse

Authentication and session abuse targets the mechanisms used to identify users and maintain access between API requests. Attackers may steal tokens, reuse credentials that should have been invalidated, automate login attempts, or take advantage of weak session controls.

Impact: Because API workflows often depend on the same token across many calls, a compromised session can provide access to multiple parts of the application. Attackers may retrieve sensitive information, modify account settings, or perform transactions on behalf of legitimate users. Long-lived tokens and weak session invalidation can extend the duration of unauthorized access.

Mitigations:

• Validate authentication on every protected request: Verify token signatures, expiration, intended audience, and applicable permissions before allowing access.
• Implement secure token lifecycle management: Use short-lived access tokens, secure token storage, refresh token rotation, and effective revocation mechanisms to limit the impact of stolen credentials.
• Strengthen authentication and session monitoring: Apply rate limiting to authentication endpoints, require multi-factor authentication where appropriate, and detect unusual login patterns, token reuse, and suspicious session activity.

Business Logic Attacks

Business logic attacks exploit flaws in how an API workflow is designed rather than weaknesses in the underlying code. The attacker uses valid functions in a way that violates the intended business rules.

Impact: Examples include repeatedly applying a discount, bypassing purchase limits, or triggering a refund without completing the required steps. These attacks can cause financial losses, inventory inconsistencies, and unauthorized changes to business records. They can be difficult to detect because individual requests may appear valid.

Mitigations:

• Enforce business rules on the server: Validate transaction conditions, eligibility requirements, pricing rules, and operational restrictions independently of client-side controls.
• Prevent duplicate and unauthorized operations: Implement transaction limits, duplicate-operation protections, and checks that verify all prerequisites before executing sensitive actions.
• Test workflows for logic abuse: Simulate repeated requests, manipulated parameters, unexpected combinations of valid actions, and attempts to bypass business restrictions.

Workflow Sequence Manipulation

Workflow sequence manipulation occurs when an attacker changes the expected order of API calls. They may skip required steps, repeat earlier actions, or call later endpoints before prerequisite checks are complete.

Impact: For example, an attacker might attempt to confirm an order before payment verification finishes. If the API does not validate the current workflow state, the attacker may bypass approvals, complete unauthorized transactions, or create inconsistent records. Repeated or out-of-order requests can also trigger duplicate actions.

Mitigations:

• Validate workflow state before every operation: Confirm that required preceding steps have been completed and that the requested action is permitted in the current state.
• Implement server-side state machines: Define valid workflow transitions and reject requests that skip mandatory steps, repeat completed actions, or execute operations out of sequence.
• Protect against duplicate requests and race conditions: Use idempotency keys, atomic transaction controls, and concurrency checks to prevent repeated or simultaneous requests from creating inconsistent results.

Excessive API Requests and Resource Consumption

Excessive API requests and resource consumption occur when attackers send large numbers of requests or trigger expensive operations to exhaust application resources. These requests may consume processing power, database connections, bandwidth, or third-party service quotas.

Impact: Resource exhaustion can slow down the application, increase operating costs, or make services unavailable to legitimate users. In multi-step workflows, attackers may repeatedly trigger expensive operations such as report generation, file processing, or external API calls. Distributed attacks can make abusive activity harder to identify through individual request metrics.

Mitigations:

• Implement rate limits and usage quotas: Restrict request frequency and resource consumption based on user identities, API tokens, IP addresses, and workflow-specific limits.
• Restrict expensive operations: Apply execution timeouts, concurrency limits, input size restrictions, and processing quotas to resource-intensive API functions.
• Monitor resource usage across complete workflows: Detect unusually frequent, repetitive, or costly sequences of API calls rather than evaluating each request independently.
• Isolate workloads and prevent cascading failures: Use circuit breakers, resource isolation, and workload prioritization to protect critical services from excessive consumption.

Map Complete API Workflows, Not Just Individual Endpoints

Security teams should understand how API endpoints connect to form complete business processes. Looking only at individual endpoints can miss risks that appear when several valid requests are combined in an unexpected sequence.

Workflow mapping should document users, services, data flows, dependencies, and state changes between steps. It should also identify which endpoints create, update, approve, or delete sensitive objects. This makes it easier to find missing controls, unexpected paths, and transitions that need stronger protection.

A complete map can also reveal undocumented or duplicate workflow paths. These may bypass newer security controls or expose older API versions that are still connected to production systems.

Establish Normal Behavioral Baselines From Runtime Traffic

Runtime traffic shows how APIs are actually used in production, including request frequency, common sequences, user behavior, and typical response patterns. These observations provide a baseline for distinguishing normal activity from unusual behavior.

Security monitoring can then flag deviations such as sudden request spikes, rare endpoint combinations, abnormal data access, or workflows completed much faster than expected. It can also detect users who perform actions at volumes or frequencies that differ significantly from similar users.

Baselines should be updated as applications, integrations, and usage patterns change. A static baseline can generate false positives or miss new forms of abuse as normal behavior evolves.

Apply Rate Limits Based on Users, Endpoints, and Workflows

Rate limits should consider more than the total number of requests sent to an API. Limits can be applied by user, token, IP address, endpoint, operation, or complete workflow depending on the risk and cost of the action.

For example, a password reset endpoint may require stricter limits than a product search endpoint. High-risk actions such as login attempts, payment requests, account creation, or data exports may need separate thresholds and cooldown periods.

Workflow-level limits can also stop attackers from distributing abusive activity across several related endpoints while staying below individual endpoint limits. Controls should account for both request volume and the number of completed business actions.

Protect APIs Against Application-Layer DDoS Attacks

Application-layer DDoS attacks target expensive API operations with requests that may appear technically valid. Attackers may repeatedly trigger database queries, searches, report generation, authentication checks, or calls to third-party services.

Defenses can include rate limiting, request validation, caching, bot detection, concurrency controls, and traffic filtering. APIs can also impose limits on expensive parameters, such as large page sizes, broad search ranges, or complex queries.

Monitoring resource use by API operation helps identify endpoints that consume disproportionate processing time, memory, database capacity, or external service quotas. This allows teams to protect the operations that create the greatest risk of resource exhaustion.

API security testing should begin during design and continue through development, deployment, and production. Teams should test authentication, authorization, input validation, rate limits, state transitions, and workflow-specific business rules.

Automated testing can catch common weaknesses early, while manual testing is useful for finding logic flaws that depend on context or request sequences. Tests should also cover negative cases, such as skipped steps, repeated requests, expired tokens, and unauthorized object access.

Production monitoring should complement predeployment testing because some risks only appear under real traffic and real workflow conditions. Findings from runtime monitoring can then be used to improve future test cases and development practices.

• Business logic attack mitigation: Automatically maps API and business logic workflows. It then generates and enforces rules that detect and block attacks abusing legitimate workflow steps.
• Continuous API discovery across environments: Provides full visibility into third-party, legacy, shadow, and deprecated APIs, so undocumented workflow paths do not go unprotected.
• Runtime posture management: Gives real-time, high-fidelity visibility into API runtime behavior. This helps teams prioritize and manage real risks that can only be detected in live production traffic.
• Contextual API testing: Runs fully automated, context-aware security tests that adapt to the application's business logic and cover the full OWASP API Top 10. Tests integrate into CI/CD pipelines, which helps teams find and fix API issues early.

• Complete runtime protection: Protects against all types of API attack vectors, including embedded attacks, API-focused bot attacks, and HTTP DDoS attacks. Comprehensive OWASP API Top 10 coverage helps organizations meet regulatory requirements.
• HTTPS DDoS protection for API endpoints: Automatically generates behavioral signatures in real time to mitigate HTTPS floods at API endpoints without blocking legitimate traffic.
• Reduced false positives: Uses AI-based automation to generate security rules from runtime production traffic and continuously adapts them for accurate detection.
• Single-portal experience: Combines discovery, management, risk assessment, and runtime protection in one portal. This simplifies management and reporting and reduces tool sprawl and silos between development and security teams.