Dev.to Security 🔐 Cybersecurity 👁 0 📖 1 min read

Moving a project to another org can leave the old org's API keys working

A lot of SaaS products let you move a project from one organization to another, often after an acquisition or when a team splits off. The move updates project.org_id and copies the members over. The API keys and deploy t

A lot of SaaS products let you move a project from one organization to another, often after an acquisition or when a team splits off. The move updates project.org_id and copies the members over. The API keys and deploy tokens created inside the project stay attached to project_id, and the auth middleware only checks that the key belongs to that project.

So the agency that built a project for a client hands it over, and the agency's CI token is still pushing to it a month later. Nobody in the new org created that token. It also doesn't show up in their org-level key list, because it was issued under the old org.

Treat the transfer as a permission change for every credential tied to the project. Either revoke project-scoped keys during the move, or store an issued_by_org_id on each key and reject the key when it no longer matches the project's current org. Right after the transfer, show the new org's admins any keys that survived and who created them, so they can decide what to keep.

To test it, create a project key in org A, transfer the project to org B, and call the API with the old key. You want a 401 or 403 back. If the call goes through, the old org still has a way in.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.