Critical: Address Security Risk in Route Protection

[hannes-sistemica]

The current implementation of route protection relies solely on client-side validation using the protectPage function. While this ensures a smooth user experience, it introduces a serious security risk:

1. Client-Side Code is Modifiable: Malicious users can bypass protectPage by disabling JavaScript or manipulating the client-side code.
2. API Data Exposure: Even if routes appear protected, API endpoints remain accessible unless server-side validation is implemented. This can result in unauthorized access to sensitive data.

Security Implications

• Unauthorized Access: An attacker could fetch data or perform actions without proper authentication.
• Data Leakage: Sensitive information exposed via unprotected APIs can be exploited.

Proposed Solution

To mitigate this risk, implement server-side validation using PocketBase:

1. Protect Routes with PocketBase:

   • Use PocketBase's hooks to enforce authentication and permissions on protected routes.
   • Alternatively, implement a reverse proxy that requires authentication before forwarding requests to the client.

2. Harden APIs:

   • Ensure API endpoints validate all authentication and permissions on the server side.
   • Use secure tokens (e.g., JWT) for authentication and verify them for every request.

3. Educate Developers:

   • Add clear documentation on how to properly secure routes and APIs using PocketBase.

Impact

This change is critical to ensuring that unauthorized users cannot bypass client-side protections and access sensitive routes or data. It will align the repository with standard security practices and enhance trust for all users.

---

⚠️ All users of this repository should be aware of this risk and avoid relying solely on client-side validation for sensitive operations.

[lucafaggianelli]

Hi, thanks for raising this point.

I think the real solution is documenting the client side behaviour because considering this is a SPA application, there is no backend that can protect the pages and of course API routes used in protected pages should be protected on their own in PocketBase.

Moreover I don't understand you solution at point 1.b: Use PocketBase's hooks to enforce authentication and permissions on protected routes. how would you implement this?

PS: is this post the result of a bot repo analysis or you're a human? either way cool :)

[hannes-sistemica]

So, I am human - but AI helped me to write as I was lazy.

Actually, when building a SaaS, that route protection needs to be done server side and not on client side. I usually use

• pocketbase as reverse proxy for a service lying behind to protect it,
• or another reverse proxy which checks the cookie
• or you can use the hook mechanism in pocketbase (where you write the endpoints as js hooks and they can check if user is logged in).

And yes, SPA applications routes not only shall, but must be protected :)