Another account can no longer assume your deployed site or bind your domain

A deployed site’s files are public: any edge node hands them out to anyone who asks. Until now, that could allow another account take a copy of your deployed site, upload it again, and become its recorded owner. From there it could delete the site or change its files. Separately, a deploy from the portal could name a project in another workspace, and bind a domain another customer had claimed to its own files.

Since 15 October, both are closed.

No incident of this has occurred. This is a proactive security fix.

What changes for you

• The first project to upload a site’s content owns it. Only that project can delete it or change its files. Redeploying from the same project, with any of its tokens, keeps it yours.
• Two projects deploying byte-identical content now conflict. The second is refused with “this content is already deployed by another project”. Any difference in any file makes the content different, so this should be rare.
• Portal deploys check that the project belongs to you. Only the control plane binds domains to sites, and only for the project that claimed them.
• Refused deploys fail visibly. A Level 0 or Level 1 portal deploy that the control plane refuses, or can’t reach, now fails with the control plane’s reason. Before, it reported success, though the site wasn’t served.

Limits

• A site uploaded with no recorded owner stays that way. This covers some older uploads. Deploying it again still works, but it doesn’t make you its owner, and only we can delete it. If you need one removed, ask through customer support.
• The fix doesn’t check backward. It closes both gaps from 15 October on.

What you need to do

Nothing. If a portal deploy now fails where it used to succeed, the message gives the control plane’s reason.