# Import flows trust client flags

Import or template flows that install services, namespaces, or relations without checking permission on each object

_Area: Web access control and IDOR. Seen in 2 disclosed reports; 2 confirmed bounties: $750 and $11,000; latest 2019-03-05. Updated 2026-10-23._

## How it works
Import and template flows take serialized objects from the client and recreate them server-side. The assumption that breaks: the importer treats the payload as data to restore, not as a request to create privileged objects. Flags and fields inside the payload (template, dependency lists, target namespace paths) are trusted as-is, and the creation code that runs afterward skips the per-object authorization it would normally enforce. A per-object import silently becomes an instance-wide or cross-tenant action.

## Where it shows up
- Import endpoints that deserialize model attributes directly, including flags like `template`, `admin`, `owner`, `visibility`.
- Template or service-install code that auto-installs imported objects on every new project/tenant.
- Config APIs with hidden or undocumented fields (e.g. dependency lists) that trigger server-side side effects.
- Import/migration endpoints accepting a target namespace or path, with auto-create logic for missing parents.
- Any flow where the caller's permission is checked on the top-level object but not on nested or referenced objects.

## How to review
For each object the import creates, ask: does the caller hold the permission to create this exact object in this exact scope? The invariant: every created object, including auto-created parents and auto-enabled dependencies, must pass the same per-object authorization as a direct API call. Check that privileged flags are stripped on import, that auto-created namespaces verify parent-level rights, and that side effects (dependency enabling, template installation) re-check permission on each target.

## Variants seen
- User-supplied `template:true` on imported services persisted as instance-wide template, auto-installed on new projects [E1](https://bugbountylibrary.com/r/h1%3A446585.md).
- Hidden `dependsOnServices` field auto-enabled arbitrary services, including private internal APIs, without the bind permission [E2](https://bugbountylibrary.com/r/blog%3Aezequiel-tech-p-5k-service-dependencies-html.md).
- Import auto-created a subgroup under an existing private namespace, granting owner access without parent permission [E3](https://bugbountylibrary.com/r/h1%3A301137.md).

## Impact and severity
Cross-tenant data exfiltration and mutation [E1](https://bugbountylibrary.com/r/h1%3A446585.md), enabling of private internal services [E2](https://bugbountylibrary.com/r/blog%3Aezequiel-tech-p-5k-service-dependencies-html.md), and unauthorized ownership of a subgroup in a private group [E3](https://bugbountylibrary.com/r/h1%3A301137.md). Severity is high because the flaw crosses tenant and role boundaries; it worsens when the imported object is instance-wide or auto-installed, multiplying reach beyond the attacker's own scope.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A446585.md
- E2: https://bugbountylibrary.com/r/blog%3Aezequiel-tech-p-5k-service-dependencies-html.md
- E3: https://bugbountylibrary.com/r/h1%3A301137.md
