You cannot really “stop” users from tampering with IDs in Reactive; anything sent to the browser can be changed. The solution is:

1. Assume the Web Block input can be manipulated
   Treat any ID (or GUID) coming from the client as untrusted. Even if you switch from an integer ID to a GUID, a malicious user can still change it if they see it in the request. Using GUIDs only makes guessing harder; it does not replace server‑side authorization checks. Secure way to pass URL parameter ID easily Gusses

2. Validate ownership/permissions on the server
   In the server logic that fetches or downloads the data (the aggregate/screen preparation/server action):

   • Get the logged‑in user with GetUserId() (from Users module). How to avoid using Input Parameter to fetch Data to avoid exposing data?
   • Filter your aggregate / SQL to only return records that belong to that user (or that they are allowed to access).

   Example pattern:

   • Input: RecordId (from Web Block)

   • Server action / aggregate filter:

     Entity.Id       = RecordId
     AND Entity.UserId = GetUserId()
     

   • If the aggregate returns 0 records, abort and show an error/empty result.

   • Only when the record is found and belongs to GetUserId() proceed with the download.

   This way, even if a hacker sends another ID, the server will not return data unless that record is linked to the logged‑in user (or passes whatever business authorization rules you define). This is the “zero‑trust” approach recommended for Reactive apps. secure server actions from manipulated input

3. Avoid relying solely on client‑side filtering
   Do not assume “if the UI only shows my own records, it’s safe”. The user can still craft a different request (Postman, browser dev tools). The check must be in the same server action that reads and/or returns the data. secure server actions from manipulated input

4. Optional: hide or harden identifiers, but keep server checks
   You can add extra layers but they never replace step 2:

   • GUID attribute:
     Add a Guid (Text) attribute to the entity, populate it with GenerateGUID() when creating the record, and use that as the input parameter instead of the numeric Id. This makes IDs hard to guess, but you still must validate that the Guid belongs to the current user before returning/downloading. Secure way to pass URL parameter ID easily Gusses
   • Encrypt parameters:
     You can encrypt/decrypt query parameters or session‑stored data, but again, on the server you must validate that the decrypted identifier is allowed for GetUserId(). Protect application, avoiding the exposure of sensitive data

5. Alternative to passing IDs in URLs
   If the concern is “clean” URLs or avoiding exposing IDs in the address bar:

   • Use local/session variables instead of URL screen inputs, and pass values through data actions / server actions. Protect application, avoiding the exposure of sensitive data
   • Or fetch the user‑specific data directly in the screen/block using GetUserId() and no Id input at all (e.g., “My Settings” page that always loads UserId = GetUserId()).

   Still, if you must identify a specific record, some identifier must travel to the client; that’s why server‑side checks are mandatory.

Summary

• You cannot fully prevent manipulation of Web Block parameters.
• You must enforce authorization in the server logic (aggregate/server action) by combining the passed ID (or GUID) with GetUserId() in filters.
• GUIDs or encryption help obfuscate, but they are only supplementary to server‑side security checks.