ExtendDO implements an ExtendDB-parity data and management surface on Cloudflare Workers, Durable Objects, SQLite storage, and R2. Security reports are most useful when they include the affected route or operation, the expected ExtendDB behavior, the observed ExtendDO behavior, and a minimal reproduction.

Do not post active exploit details, private credentials, customer data, or R2 object contents in a public issue.

Preferred reporting path:

1. Use GitHub's private vulnerability reporting or Security Advisories feature for this repository when it is available.
2. If private reporting is not available, contact the repository owner through GitHub and request a private disclosure channel before sharing exploit details.

Public issues are fine for non-sensitive hardening suggestions, documentation gaps, or behavior mismatches that do not expose a live exploit.

Production deployments should:

• Set EXTENDDO_ADMIN_USER and EXTENDDO_ADMIN_PASSWORD as Wrangler secrets.
• Keep the default SigV4-required data-plane behavior enabled for public and production deployments.
• Use environment-specific Worker and R2 bucket names in ignored local wrangler.jsonc copied from wrangler.example.json.
• Keep .dev.vars, .wrangler/, generated bundles, and local R2 test data out of version control.
• Treat access key secrets returned by the management API as one-time display values and store them in a dedicated secret manager.
• Restrict who can deploy the Worker and mutate Durable Object migrations.

Management requests always require Basic authentication. DynamoDB JSON requests require SigV4 credentials by default. EXTENDDO_ALLOW_UNAUTHENTICATED=true routes unsigned requests to the default local account and is intended only for local development and controlled test deployments.

The public compatibility target is ExtendDB parity on Cloudflare Workers, not full AWS service parity. AWS-only management features that ExtendDB does not implement are intentionally outside the supported surface and should remain unroutable.

Before publishing or cutting a release, run a secret scan over both the current tree and git history. The repository contains test fixtures and AWS SigV4 example credentials; scanners may flag those placeholders, but real credentials must never be committed.