TL;DR:
In my testing, files can remain accessible via direct URLs even after a page is unshared or content is deleted, meaning previously shared files may still be reachable if someone has the link.

I was testing a workflow in ByDesign and noticed something I wanted to share and sanity-check with others.

**Result:** In my testing, the file continued to load via the direct URL in these scenarios.
**Notably, this included cases where content had been deleted, indicating that files may remain accessible via previously obtained links even after users attempt to remove them.**

What I tested

Across multiple flows (pages and chat attachments):

1. Upload a file to a page or share content
2. Obtain the direct file URL
3. Unshare the page or delete the content (including clearing trash)
4. Revisit the direct URL

Result: In my testing, the file continued to load via the direct URL in these scenarios.

Why this matters

If access revocation doesn’t fully propagate to underlying storage:

* Previously shared files may remain accessible after “unshare” or deletion * Links saved by collaborators, emails, or logs could continue to work * Users may assume content is no longer accessible when it still is via direct links

Example scenarios

* A file shared with a client remains accessible after access is revoked * Internal documents shared temporarily remain accessible after cleanup * Attachments shared in chat remain accessible even after deletion

Expected behavior

* Access should be revoked or rotated when permissions change * File URLs should no longer resolve after deletion/unshare * Access control should be enforced consistently at the storage level

Disclosure

I reported this privately to the team via support and email and shared reproduction details. I have not received a response so far, and wanted to raise awareness in case others are relying on similar workflows.

Part of the behavior appears to have been addressed, but I was still able to reproduce access under additional conditions during retesting.

I have intentionally not included any live links or sensitive data here, even though I was able to access files after deletion in testing, to avoid any potential misuse.

For users

Until clarified or resolved:

* Avoid relying solely on “unshare” or “delete” for sensitive files * Consider rotating or replacing previously shared sensitive content

TL;DR:
In my testing, files can remain accessible via direct URLs even after a page is unshared or content is deleted, meaning previously shared files may still be reachable if someone has the link.Why bydesign keeping files on server even after user deleted files?

I was testing a workflow in ByDesign and noticed something I wanted to share and sanity-check with others.

Result: In my testing, the file continued to load via the direct URL in these scenarios.
Notably, this included cases where content had been deleted, indicating that files may remain accessible via previously obtained links even after users attempt to remove them.

What I tested

Across multiple flows (pages and chat attachments):

1. Upload a file to a page or share content
2. Obtain the direct file URL
3. Unshare the page or delete the content (including clearing trash)
4. Revisit the direct URL

Result: In my testing, the file continued to load via the direct URL in these scenarios.

Why this matters

If access revocation doesn’t fully propagate to underlying storage:

• Previously shared files may remain accessible after “unshare” or deletion
• Links saved by collaborators, emails, or logs could continue to work
• Users may assume content is no longer accessible when it still is via direct links

Example scenarios

• A file shared with a client remains accessible after access is revoked
• Internal documents shared temporarily remain accessible after cleanup
• Attachments shared in chat remain accessible even after deletion

Expected behavior

• Access should be revoked or rotated when permissions change
• File URLs should no longer resolve after deletion/unshare
• Access control should be enforced consistently at the storage level

Disclosure

I reported this privately to the team via support and email and shared reproduction details. I have not received a response so far, and wanted to raise awareness in case others are relying on similar workflows.

Part of the behavior appears to have been addressed, but I was still able to reproduce access under additional conditions during retesting.

I have intentionally not included any live links or sensitive data here, even though I was able to access files after deletion in testing, to avoid any potential misuse.

For users

Until clarified or resolved:

• Avoid using share option. If you share page, it creates direct links which can be accessed by other even if unshared or deleted.

• Avoid uploading sensitive data to bydesign

TL;DR:
In my testing, files can remain accessible via direct URLs even after a page is unshared or content is deleted, meaning previously shared files may still be reachable if someone has the link.Why bydesign keeping files on server even after user deleted files?

I was testing a workflow in ByDesign io productivity app and noticed something I wanted to share and sanity-check with others.

Result: In my testing, the file continued to load via the direct URL in these scenarios.
Notably, this included cases where content had been deleted, indicating that files may remain accessible via previously obtained links even after users attempt to remove them.

What I tested

Across multiple flows (pages and chat attachments):

1. Upload a file to a page or share content
2. Obtain the direct file URL
3. Unshare the page or delete the content (including clearing trash)
4. Revisit the direct URL

Result: In my testing, the file continued to load via the direct URL in these scenarios.

Why this matters

If access revocation doesn’t fully propagate to underlying storage:

• Previously shared files may remain accessible after “unshare” or deletion
• Links saved by collaborators, emails, or logs could continue to work
• Users may assume content is no longer accessible when it still is via direct links

Example scenarios

• A file shared with a client remains accessible after access is revoked
• Internal documents shared temporarily remain accessible after cleanup
• Attachments shared in chat remain accessible even after deletion

Expected behavior

• Access should be revoked or rotated when permissions change
• File URLs should no longer resolve after deletion/unshare
• Access control should be enforced consistently at the storage level

Disclosure

I reported this privately to the team via support and email and shared reproduction details. I have not received a response so far, and wanted to raise awareness in case others are relying on similar workflows.

Part of the behavior appears to have been addressed, but I was still able to reproduce access under additional conditions during retesting.

I have intentionally not included any live links or sensitive data here, even though I was able to access files after deletion in testing, to avoid any potential misuse.

For users

Until clarified or resolved:

• Avoid using share option. If you share page, it creates direct links which can be accessed by other even if unshared or deleted.
• Avoid uploading sensitive data to bydesign

TL;DR:

ByDesign app is not deleting your files and their “Share” feature is broken. Even after you unshare a page, permanently delete it, and empty the trash, the Firebase public links to your sensitive files stay fully active. Anyone with a cached or saved link can still access them — no account needed. They’re hoarding deleted user data and ignoring responsible disclosures.

I do independent security research and what I’ve discovered with ByDesign (the productivity app running the current AppSumo lifetime deal) is genuinely alarming.

The Full Nightmare:

• You share a page using ByDesign’s official share option.
• You later unshare it.
• You permanently delete the page/file and empty the trash.
• You may even delete the entire workspace.

Despite all of that, the direct Firebase public links for files inside that page remain active and fully downloadable by anyone on the internet.

No login. No authentication. The files are still hosted on ByDesign’s servers long after you told them to delete everything.

This affects sensitive files (documents, images, contracts, proposals, client work, etc.) that were ever inside a shared page.

What they did when I reported it:

They only disabled the exact links I sent them as proof. The underlying files were not deleted. When I tested again through different workflows (including their Chat feature), the problem persisted — deleted + unshared content is still publicly accessible.

Firebase links also appear dangerously predictable, making mass scraping a serious risk for anyone who understands the pattern.

Responsible Disclosure = Completely Ghosted

• Reported via support chat → Acknowledged but only cosmetic fixes applied.
• Emailed founder directly with live proof → Ignored.
• Multiple detailed follow-ups showing the issue still exists after their “fix” → Radio silence.

This is not a small bug. This is a major GDPR/privacy incident waiting to explode. Businesses and freelancers using ByDesign for client work are unknowingly exposing their data even after “deleting” and “unsharing.”

If you are using ByDesign right now:

• Assume every file you ever uploaded to a shared page is still publicly accessible via old links.
• Cached links from clients, partners, or anyone else will continue to work.
• Stop uploading anything sensitive immediately.
• Export your important data and consider leaving the platform.

Founders of ByDesign:

Fix this properly and transparently. Implement real hard deletion from Firebase, fully revoke/invalidate all links on unshare + delete (across all features including Chat), and stop retaining user data after users delete it.

I have multiple live, working public links to files and pages I fully deleted and unshared. I’m not posting them here because I don’t want to enable hackers to exploit predictable Firebase patterns. Proof is available to the team and legitimate security researchers.

This post will stay up until ByDesign actually resolves the issue instead of applying bandaids.

Your “deleted” and “unshared” files are likely still out there for anyone to access.