Update backend-only var and auth docs w.r.t. app security

docs/authentication/authentication_overview.md

@@ -1,13 +1,25 @@
+```python exec
+from pcweb.pages.docs import vars
+```
+
 # Authentication Overview
 
 Many apps require authentication to manage users. There are a few different ways to accomplish this in Reflex:
 
-We have solutions here:
+We have solutions that currently exist outside of the core framework:
 
-1. Local Auth: Uses your own database: https://github.com/reflex-dev/reflex-examples/tree/main/twitter
-2. Google Auth: Uses sign in with Google: https://reflex.dev/blog/2023-10-25-implementing-sign-in-with-google/
+1. Local Auth: Uses your own database: https://github.com/masenf/reflex-local-auth
+2. Google Auth: Uses sign in with Google: https://github.com/masenf/reflex-google-auth
 3. Captcha: Generates tests that humans can pass but automated systems cannot: https://github.com/masenf/reflex-google-recaptcha-v2
 4. Magic Link Auth: A passwordless login method that sends a unique, one-time-use URL to a user's email: https://github.com/masenf/reflex-magic-link-auth
 5. Clerk Auth: A community member wrapped this component and hooked it up in this app: https://github.com/TimChild/reflex-clerk-api
 
+## Guidance for Implementing Authentication
+
+- Store sensitive user tokens and information in [backend-only vars]({vars.base_vars.path}#backend-only-vars).
+- Validate user session and permissions for each event handler that performs an authenticated action and all computed vars or loader events that access private data.
+- All content that is staticly rendered in the frontend (for example, data hardcoded or loaded at compile time in the UI) will be publicly available, even if the page redirects to a login or uses `rx.cond` to hide content.
+- Only data that originates from state can be truly private and protected.
+- When using cookies or local storage, a signed JWT can detect and invalidate any local tampering.
+
 More auth documentation on the way. Check back soon!

docs/vars/base_vars.md

@@ -77,15 +77,29 @@ def ticker_example():
 
 ## Backend-only Vars
 
-Any Var in a state class that starts with an underscore is considered backend
-only and will not be synchronized with the frontend. Data associated with a
-specific session that is not directly rendered on the frontend should be stored
-in a backend-only var to reduce network traffic and improve performance.
+Any Var in a state class that starts with an underscore (`_`) is considered backend
+only and will **not be synchronized with the frontend**. Data associated with a
+specific session that is _not directly rendered on the frontend should be stored
+in a backend-only var_ to reduce network traffic and improve performance.
 
 They have the advantage that they don't need to be JSON serializable, however
-they must still be cloudpickle-able to be used with redis in prod mode. They are
-not directly renderable on the frontend, and may be used to store sensitive
-values that should not be sent to the client.
+they must still be pickle-able to be used with redis in prod mode. They are
+not directly renderable on the frontend, and **may be used to store sensitive
+values that should not be sent to the client**.
+
+```md alert warning
+# Protect auth data and sensitive state in backend-only vars.
+
+Regular vars and computed vars should **only** be used for rendering the state
+of your app in the frontend. Having any type of permissions or authenticated state based on
+a regular var presents a security risk as you may assume these have shared control
+with the frontend (client) due to default setter methods.
+
+For improved security, `state_auto_setters=False` may be set in `rxconfig.py`
+to prevent the automatic generation of setters for regular vars, however, the
+client will still be able to locally modify the contents of frontend vars as
+they are presented in the UI.
+```
 
 For example, a backend-only var is used to store a large data structure which is
 then paged to the frontend using cached vars.