New to Claude Skills? Learn how to install them →

Pprowler-cloud on GitHub

Prowler Test API

Free

Streamline testing for Prowler's API with best practices.

Get this skill

Free · Opens the source repo

What Prowler Test API does

Prowler Test API is designed to facilitate the testing of Prowler's API by providing a structured approach to writing tests for JSON:API requests, RBAC (Role-Based Access Control), and Celery tasks. This skill is particularly useful for developers working with Prowler's backend services, as it encapsulates critical testing patterns and rules that ensure robust and secure API interactions. The skill emphasizes the importance of adhering to specific conventions, such as the correct usage of content types and response handling, which are crucial for maintaining API integrity.

The skill includes a comprehensive set of rules that guide users in writing effective tests. For instance, it mandates the use of response.json()["data"] for accessing response data, and specifies the correct content types for PATCH/PUT and POST requests. Additionally, it highlights the necessity of testing cross-tenant isolation, ensuring that resources are appropriately secured and inaccessible across different tenants. This focus on security and adherence to best practices makes it an essential tool for developers looking to maintain high standards in their API testing workflows.

Moreover, Prowler Test API provides a rich set of fixtures that simplify the setup of test environments. These fixtures allow for the creation of test users, tenants, and various provider types, streamlining the process of writing and executing tests. By utilizing these fixtures, developers can ensure that their tests are both comprehensive and efficient, covering a wide range of scenarios including RBAC permissions and async task logic.

Overall, Prowler Test API is a valuable resource for developers aiming to implement thorough testing practices in their Prowler API projects. It not only saves time by providing ready-to-use patterns and fixtures but also enhances the reliability and security of the API through rigorous testing methodologies.

When to use it

Use this skill when developing or maintaining tests for Prowler's API, especially when working with JSON:API requests and RBAC.

When not to use it

This skill may not be suitable for testing APIs outside of the Prowler ecosystem or for developers unfamiliar with Prowler's architecture.

What you can build with it

Testing JSON:API Requests

Utilize the skill to ensure that your JSON:API requests are correctly formatted and that responses are handled properly.

Validating RBAC Permissions

Use the provided fixtures to test various RBAC scenarios, ensuring that permissions are enforced as expected.

Mocking Celery Tasks

Implement the recommended mocking strategies for testing Celery tasks, allowing for reliable and isolated tests.

How to install Prowler Test API

View source

1. Install with the skills CLI

npx skills add prowler-cloud/prowler/prowler-test-api --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by prowler-cloud

Critical Rules

  • ALWAYS use response.json()["data"] not response.data
  • ALWAYS use content_type = "application/vnd.api+json" for PATCH/PUT requests
  • ALWAYS use format="vnd.api+json" for POST requests
  • ALWAYS test cross-tenant isolation - RLS returns 404, NOT 403
  • NEVER skip RLS isolation tests when adding new endpoints
  • NEVER use realistic-looking API keys in tests (TruffleHog will flag them)
  • ALWAYS mock BOTH .delay() AND Task.objects.get for async task tests

1. Fixture Dependency Chain

create_test_user (session) ─► tenants_fixture (function) ─► authenticated_client
                                     │
                                     └─► aws_provider ─► scans_fixture ─► findings_fixture

Key Fixtures

FixtureDescription
create_test_userSession user (dev@prowler.com)
tenants_fixture3 tenants: [0],[1] have membership, [2] isolated
authenticated_clientDjango test client with JWT for tenant[0]
authenticated_client_for_tenant_factoryCreates a Django test client with JWT for a specific user and tenant
provider_factoryCreates one validated provider with provider-specific defaults
aws_provider1 AWS provider in tenant[0]
aws_provider_pair2 AWS providers in tenant[0]
all_provider_types_fixture1 provider for every supported provider type
tasks_fixture2 Celery tasks with TaskResult

RBAC Fixtures

FixturePermissions
authenticated_client_rbacAll permissions (admin)
authenticated_client_rbac_norolesMembership but NO roles
authenticated_client_no_permissions_rbacAll permissions = False

Use authenticated_client for normal view behavior tests. It uses a cheap JWT and still runs the real request authentication path. Use serializer-generated JWTs or API-key clients only when the test is specifically about token obtain/refresh, invalid tokens, expired tokens, tenant switching by token, API keys, or unauthenticated 401 behavior. Use authenticated_client_for_tenant_factory when a test needs a cheap JWT client for a different user or tenant.


2. JSON:API Requests

POST (Create)

response = client.post(
    reverse("provider-list"),
    data={"data": {"type": "providers", "attributes": {...}}},
    format="vnd.api+json",  # NOT content_type!
)

PATCH (Update)

response = client.patch(
    reverse("provider-detail", kwargs={"pk": provider.id}),
    data={"data": {"type": "providers", "id": str(provider.id), "attributes": {...}}},
    content_type="application/vnd.api+json",  # NOT format!
)

Reading Responses

data = response.json()["data"]
attrs = data["attributes"]
errors = response.json()["errors"]  # For 400 responses

3. RLS Isolation (Cross-Tenant)

RLS returns 404, NOT 403 - the resource is invisible, not forbidden.

def test_cross_tenant_access_denied(self, authenticated_client, tenants_fixture):
    other_tenant = tenants_fixture[2]  # Isolated tenant
    foreign_provider = Provider.objects.create(tenant_id=other_tenant.id, ...)

    response = authenticated_client.get(reverse("provider-detail", args=[foreign_provider.id]))
    assert response.status_code == status.HTTP_404_NOT_FOUND  # NOT 403!

4. Celery Task Testing

Testing Strategies

StrategyUse For
Mock .delay() + Task.objects.getTesting views that trigger tasks
task.apply()Synchronous task logic testing
Mock chain/groupTesting Canvas orchestration
Mock connectionTesting @set_tenant decorator
Mock apply_asyncTesting Beat scheduled tasks

Why NOT task_always_eager

ProblemImpact
No task serializationMisses argument type errors
No broker interactionHides connection issues
Different execution contextself.request behaves differently

Instead, use: task.apply() for sync execution, mocking for isolation.

Full examples: See assets/api_test.py for TestCeleryTaskLogic, TestCeleryCanvas, TestSetTenantDecorator, TestBeatScheduling.


5. Fake Secrets (TruffleHog)

# BAD - TruffleHog flags these:
api_key = "sk-test1234567890T3BlbkFJtest1234567890"

# GOOD - obviously fake:
api_key = "sk-fake-test-key-for-unit-testing-only"

6. Response Status Codes

ScenarioCode
Successful GET200
Successful POST201
Async operation (DELETE/scan trigger)202
Sync DELETE204
Validation error400
Missing permission (RBAC)403
RLS isolation / not found404

Commands

cd api && uv run pytest -x --tb=short
cd api && uv run pytest -k "test_provider"
cd api && uv run pytest api/src/backend/api/tests/test_rbac.py

Resources

Frequently asked questions about Prowler Test API

Similar skills