Akto - API Security platform
Akto WebsiteStart freeBook a demoDiscordGitHub
  • Github Open Source Repo
  • What is Akto?
  • AktoGPT
  • AGENTIC AI
    • Akto MCP Server
  • Getting Started
    • Deployment Types
    • Akto Cloud
      • Connect Akto with Hybrid SaaS
      • Migrate From Self Hosted Setup To SaaS
      • Setting up proxy
    • Akto Self Hosted
      • AWS deploy
        • AWS multi-VPC deploy
        • AWS Cross-Region Cross-VPC deploy
        • Custom subdomain on Akto on AWS
      • Helm Deploy
      • Azure Deploy
      • Openshift Deploy
      • Heroku
      • GCP Deploy
    • Local Deploy
    • FAQs on data concerns
  • Traffic Connector
    • Traffic Data Sources
    • eBPF
      • Connect Akto with eBPF
      • Connect Akto with eBPF on mTLS
    • Kubernetes
      • Connect Akto with Kubernetes in AWS
      • Connect Akto eBPF with Kubernetes
    • API Gateways
      • Connect Akto with Envoy
      • Connect Akto with NGINX
      • Connect Akto with Istio
      • Connect Akto with HAProxy
      • Connect Akto with Azure API Management
      • Connect Akto with F5
      • Connect Akto with 3Scale
      • Connect Akto with Layer7 API Gateway
      • Connect Akto with Citrix
      • Connect Akto with Kong
      • Connect Akto with Kong Mesh
      • Connect Akto with Cloudflare
      • Connect Akto with IBM Connect
      • Connect Akto with Mulesoft Flex Gateway
      • Connect Akto with Apigee
    • Mirroring
      • Connect Akto with AWS Traffic Mirroring
      • Connect Akto with GCP Packet Mirroring
    • AWS Services
      • Connect Akto with AWS Beanstalk
      • Connect Akto with AWS API Gateway
      • Connect Akto with AWS Lambda
      • Connect Akto with AWS API Gateway with CloudWatch OAM
      • Connect Akto with AWS API Gateway with service account (Temporary Credentials)
      • Connect Akto with AWS Fargate
      • Connect Akto with AWS EKS
      • Connect Akto with AWS ECS
    • GCP Services
      • Connect Akto with GCP Packet Mirroring
      • Connect Akto with Apigee
      • Connect Akto with Google Cloud Run Functions
      • Connect Akto with Google Cloud Run
      • Connect Akto with GKE
    • Azure Services
      • Connect Akto with Azure App Services
      • Connect Akto with Azure API Management
      • Connect Akto with AKS
      • Connect Akto with Azure OpenShift
      • Connect Akto with Azure Container App
      • Connect Akto with Azure Functions
    • Akto SDK
    • Source Code
      • GitHub
      • Bitbucket
      • GitLab
      • API inventory from source code
      • Source code installation
    • Virtual Machines
      • Connect Akto with Docker
      • Connect Akto on TLS service
      • Connect Akto with TCP Agent
    • Manual
      • Connect Akto with Burp suite
      • Connect Akto with Postman
      • Connect Akto with OpenAPI
      • Add API traffic to Akto using HAR file upload
      • API Import: WSDL in Akto
    • Configure TLS on kafka
  • API Inventory
    • Concepts
      • API Endpoints
      • Meta Properties of API Endpoint
      • API Collection
      • API Call Stats
      • Explore mode
      • gRPC API Coverage with Akto
      • Data Types
      • API Groups
      • Environment Type
      • Protocol Support in Akto
      • API Changes
      • Third Party APIs
      • Tags
      • API Dependency Graph
      • Sensitive Data
      • Alerts
      • Shadow APIs
      • Zombie APIs
      • Risk Score
      • Auth types
      • Access Type
      • API discovery from source code
      • Advanced Filter Option
    • How-To
      • Enable Tree view for API collections
      • Export an API Collection to Postman
      • Export an API Collection to Burp
      • Create API group
      • Collection-Based RBAC
      • Descriptions for API Collections & Endpoints
      • Remove API(s) from API group
      • Deactivating and Reactivating API Collections in Akto
      • Add collection using Explore Mode
      • De-merge API
      • Create Swagger File Using Akto
      • Copy API Endpoints Data
      • Add an API Collection
      • Set environment type
      • Delete an API Collection
      • Create a Custom Data Type
      • Reset Data Types in Akto
      • Set Sensitivity of a Data Type
      • De-activate a data type
      • Add a Custom Auth Type
      • Reset an Auth Type
      • Configure Access Types
      • View New API Endpoint
      • Add Private CIDRs list
      • View New Parameters
      • Configure alerts on API changes
      • Create a custom collection
      • Redact sensitive data
      • Extract APIs from github hosted source code using our Github Action
      • Extract APIs from source code using our Docker based CLI
      • Remove Bad Endpoints
      • Create New Tags
      • Edit Tags
  • API Protection
    • Overview
    • External API Runtime Threat Notifications
    • Concepts
      • Threat Actors
      • Threat Policy
  • WAF
    • AWS WAF
    • Cloudflare WAF
  • Test Editor
    • Concepts
      • Overview
      • Test YAML
      • Test Library
      • Custom Test
      • Test YAML Syntax (Detailed)
        • ID
        • Info
        • Wordlists
        • Auth
        • API Selection Filters
        • Execute
        • Validation
        • Contexts
        • Strategy
        • Conditional flows
      • Template YAMLs
        • Local File Inclusion with Akto
      • Dynamic severity
    • How To
      • Edit Test
      • Create a Custom Test
      • Deactivate Test
      • Play in Test Editor Background
      • Copy Test Content
      • Opening Endpoint in Test Editor
      • Add a New Test Library
      • Contribute to Test Library
  • API Security Testing
    • Concepts
      • Severity Levels
      • Test
      • Result types
      • Test Role
      • User Config
      • Test Result
      • JSON Recording for Automated Auth Tokens
    • How To
      • Run Test
      • Auto-Create Jira Tickets
      • Edit Test Settings
      • Install testing module in your Cloud
        • Ephemeral Storage for Hybrid Runtime
        • gRPC Testing in Hybrid Testing Module
      • Create Custom Test Suites
      • Recalculate Issue Counts
      • Testing Module Selector in Akto
      • Run Tests by Category
      • Export Vulnerability Report from Test Results
      • Test Multiple APIs
      • Schedule Tests
      • Stop Tests
      • Run Test on Any One Endpoint
      • Configure global rate limit
      • Rescan Specific Issues Resolved
      • Configure Pre-request Script
      • Set Up JSON Recording for Auth Tokens
      • Create a Test Role
      • Edit Auth Flow in Test Roles
      • Restrict Access to a Test Role Using RBAC
      • Play in Test Editor Playground
      • Conduct Role-Based Testing
      • Run tests in CLI using Akto
      • Secure GraphQL APIs using Akto
      • Secure REST APIs using Akto
      • Secure SOAP APIs using Akto
      • Create and Edit Auth Types
  • Issues
    • Concepts
      • Overview
      • Values
      • Vulnerability Report
      • Remediation
    • How To
      • Jira Integration
      • Azure DevOps Boards Integration
      • Triage Issues
        • Review Issues Marked as False Positives
      • Export Selected Issues to Reports
      • Export Vulnerability Report
  • CI/CD
    • GitHub Actions
      • Create GitHub App
    • Jenkins
    • Azure DevOps
    • GitLab
    • Generic CI/CD
    • How To
      • Run tests in CI/CD
      • Add test to CI/CD Pipeline
      • Get API Credentials
      • Test ID from Akto test
  • Account
    • Invite User
      • Change role of a User
    • Create a New Account
    • How to Switch Between Accounts in Akto
    • Understanding Role Permissions
    • Custom roles
    • Audit Logs
    • SSO
      • Azure AD SAML
      • Okta OIDC
      • Github OIDC
      • Google Workspace SSO
      • Add Members From SSO
  • Compliance
    • Concepts
      • Overview
  • API security posture
    • Concepts
      • Overview
  • SIEM Integration
    • Splunk
  • Alerts
    • Slack Webhook
    • Microsoft Teams Webhook
    • Setup alerts for Akto test run results
  • Pricing
    • Pricing Plans
    • How To
      • Upgrade Your Plan
      • Downgrade Your Plan
      • Sync Usage Data
  • API reference
    • API reference
  • Components
    • Dashboard
    • Testing module
    • Traffic mirroring module
    • Runtime analyzer
    • Context analyzer
    • Puppeteer server
    • Other OSS
    • robots.txt
  • Troubleshooting
    • How to get logs
    • How to disable logging
    • How to update helm deployments
  • Stay Updated on New Releases
  • Support
Powered by GitBook
On this page
  • Roles access context
  • API Inventory context
  • Parameters context
  • Private variable context

Was this helpful?

  1. Test Editor
  2. Concepts
  3. Test YAML Syntax (Detailed)

Contexts

You can use information from all of your Akto dashboard in your YAML test.

PreviousValidationNextStrategy

Last updated 1 year ago

Was this helpful?

Simple API Security testing involves fuzzing API with standard wordlists. However, to make testing really powerful, you'd need real data from your application. Eg. instead of trying incremental user_id=1, user_id=2, user_id=3, etc., you would want to try with user_ids that actually exist in your system eg. user_id=3489, user_id=3259.

Contexts will help you query all your data from Akto dashboard - which you can then use in your YAML tests.

Akto supports 4 types of contexts -

  1. (roles_access_context) - You can access tokens from that you have configured in the dashboard

  2. (endpoint_in_traffic_context) - You can use this context to check if an endpoint already exists in API Inventory. This is useful while discovering shadow APIs. An endpoint is a shadow endpoint only if it exists and is NOT being used by the application.

  3. (param_context) - You can use this context to query all parameters (JSON/form-data etc.). For example, you want to run a BOLA test that tries to access cart details by changing cart_id parameter in the request body. You can use param_context to query all keys that match .*cart_id.* and use this wordlist in your BOLA test.

  4. (private_variable_context) - You can use this context to find out if a particular value is being used by exactly 1 user or multiple users. A cart_id or a transaction_id is particular to a user, whereas product_id can be queried by multiple users

Roles access context

Once you in Akto dashboard and for that role, you can use the auth tokens in your YAML test.

Example - You want to test each admin API if they can be accessed using a member token. To carry out this test, you can create a role called MEMBER_TOLE . You would also have to add auth token to the role (eg Authorization: Bearer member.role.token) . You can now use it in your YAML to replace the auth token header.

Sample YAML -

api_selection_filters:
  url:
    contains: "/admin"
execute:
  type: single
  requests:
    - req:
      - modify_header:
          ${roles_access_context.MEMBER}: 1       
validate:
  response_code:
    gt: 200
    lt: 300          

This YAML runs only on endpoints that contain /admin (assuming these are admin APIs). It replaces the auth token in the original request by MEMBER auth token. If the response is 2xx, it is a vulnerability

API Inventory context

You can use this context to find out if an endpoint exists in API Inventory.

Example - You want to fuzz and find out all shadow endpoints which are NOT a part of API Inventory already.

wordlists:
  fuzzWords:
    user
    account
    customer
execute:
  requests:
    - req:
        modify_url: ${url}/${fuzzWords}
        
validate:
  response_code:
    gt: 200
    lt: 300
  endpoint_in_traffic_context: false   
  # raise Shadow-endpoint-found vuln only if the fuzzed endpoint is NOT in API Inventory

Parameters context

You can query all if your API traffic to extract list of user_id. You can extract this info in a variable (eg user_context). Say your API traffic contains the following parameters (across payloads, query params etc.) -

  • user: 23

  • user: 89

  • user_id: 56723

  • customer: 78193

You can then use user_context.key and user_context.value

api_selection_filter:
  param_context:
    param: user|customer    # find all user or customer values from API traffic.
    extract: user_context
execute:
  type: single
  requests:
    - req:
      - add_query_param:
          user_context.key: ${user_context.value} # add query param user=123 

This will fire 4 API calls - with the following query param one by one -

  • user=23

  • user=89

  • user_id=56723

  • customer=78193

Private variable context

You can use this context to find out if a particular value is being used by exactly 1 user or multiple users. Consider an e-commerce application (eg juice-shop).

Example of a public variable - The product-details of sku_id 9 is fetched using /api/v1/product?sku_id=9 . It is accessible by all users. We can validate it from the traffic also. Multiple users will be accessing the same endpoint - /api/v1/product?sku_id=9 successfully. Here sku_id is sort-of a public variable because all products can be accessed by all users.

Example of a private variable - Imagine a similar scenario, but for cart_id this time. The cart details of cart_id 98 are fetched using /api/v1/cart?cart_id=98. Unlike product_id, cart_id should NOT be accessible by more than 1 user.

Akto can differentiate between the usage behavior of cart_id and product_id. Akto will classify cart_id as private and product_id as public.

Note that private vs public variable depends a lot on traffic. These work very well if you are using automated traffic connectors. If you connect your staging or prod server, Akto will receive traffic from multiple users across several sessions that really improves this private vs public classification. If you are using BurpSuite, Postman etc., it is very likely that they contain only 1 user's data. The result in that case aren't good.

Say, you want to test APIs that use private variables (eg /api/v1/cart/123, /api/v1/order/78 etc.) for BOLA vulnerability. Simply replace the auth header by an attacker token (note that running the same test on /api/v1/product/9 will give a false positive and should NOT be tested for BOLA)

api_selection_filters:
  private_variable_context:
    gt: 0
execute:
  type: single
  requests:
    - req:
        modify_header:
          replace_auth_header: true

This will exclude /api/v1/product/9 and filter only cart and order APIs - /api/v1/cart/123, /api/v1/order/78.

By default, all variables are considered to be private. Only with more data (from multiple users across several sessions), Akto will start marking some variables as private.

You can also associate other operators such as regex: ".*user.*" - to filter only those vars that contain the string user.

Test roles
create a Test role
Roles
API Inventory
Parameters
Private variable
configure auth tokens