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

Your trash folder can list deleted records the user was never allowed to open

Most apps check access on the live record and stop caring once it's deleted. The trash page runs its own query, something like deleted_at IS NOT NULL AND workspace_id = ?, and shows every row it finds. Titles and owners

Most apps check access on the live record and stop caring once it's deleted. The trash page runs its own query, something like deleted_at IS NOT NULL AND workspace_id = ?, and shows every row it finds. Titles and owners show up for anyone who can open the trash.

So a member of a shared workspace opens the bin and sees "Q4 reorg plan", a doc that sat in a private folder they never had access to. Some apps also let them hit Restore, and the doc comes back with them listed as the last editor.

Run the same read check on the trash list that you run on the normal list, using the permissions the record had right before it was deleted. That means keeping the parent folder ID on the deleted row so the check still has something to look at. Treat restore as its own check: the user needs edit rights on the record and write access to the folder it's going back into. If you'd rather keep permanent delete for admins only, that's fine, but the trash list itself should never show more than the user could see before.

To test it, put a doc in a private folder as one user, delete it, then open the trash as a second user who isn't in that folder. If the title shows up, your trash view skips the permission check.

📰 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.