6.4 Anonymous Users & Public Access

6.4 Anonymous Users & Public Access

Exam Focus: Anonymous user support enables public-facing low-code portals, e-commerce stores, and customer intake forms. The Intermediate Developer exam focuses on how to enable anonymous access in Project Security, assign isolated guest roles, manage session transitions during user login without losing state, safeguard public microflows, and prevent Denial-of-Service (DoS) and malicious file injection attacks through unauthenticated file upload forms.

Not all business applications operate entirely behind corporate Single Sign-On (SSO) or employee login screens. Many enterprise solutions—such as public citizen service portals, warranty registration tools, customer self-onboarding flows, and insurance quote calculators—require unauthenticated public users to access the application before creating or logging into an account.

---

Architectural Overview of Anonymous Access

When a public visitor navigates to a Mendix application URL in their web browser:

1. Initial Connection: If the user does not possess an active session cookie, the Mendix Runtime checks Project Security > Anonymous Users.
2. Session Generation: If anonymous access is enabled, the runtime generates a temporary, in-memory Anonymous Session and assigns the user the designated Anonymous User Role.
3. Session Identification: The client browser receives a standard Mendix session cookie (XASSESSIONID) linking subsequent HTTP requests to this anonymous server session.
4. Security Enforcement: The anonymous user can only navigate to pages, execute microflows, and read entity data explicitly permitted for their assigned guest role under Production Security rules.

---

Configuring Anonymous Access in Project Security

Enabling anonymous access requires four precise configuration steps in Studio Pro's Project Security editor:

PROJECT SECURITY > ANONYMOUS USERS
├── 1. Allow anonymous users: Set to 'Yes'
├── 2. Anonymous user role: Select dedicated role (e.g., 'Guest')
├── 3. Sign-in page: Select login form (e.g., 'Account.Login_Page')
└── 4. Sign-in microflow: Optional custom authentication handler

The Golden Rule of Guest Role Isolation

Security Rule: Never map the Anonymous User Role to standard authenticated module roles (such as User, Employee, or Customer). Always create a dedicated, isolated User Role named Guest or Anonymous.

Principle of Least Privilege for the Guest Role:

• Read-Only by Default: The Guest role should only have Read access to public reference data (such as product categories, FAQ articles, or public branch locations).
• No Delete Privileges: Anonymous users must never be granted Delete permissions on any persistable entity.
• Restricted Creation Rights: Restrict Create permissions exclusively to non-persistable entities (NPEs) used for transient UI wizards, or staging entities specifically designed for public intake (e.g., JobApplicationStaging).
• Microflow Scoping: Microflows exposed to anonymous users must have Apply entity access = Yes enabled to guarantee that client-side invocations cannot bypass domain security boundaries.

The Sign-In Workflow & Session Transition

A critical challenge in public-facing applications occurs when an anonymous visitor transitions into an authenticated user (for example, an anonymous shopper logging in during checkout):

Defending Against Session Fixation Attacks

In a Session Fixation attack, an adversary tricks a victim into authenticating using a pre-allocated session identifier known to the attacker. If the application keeps the same session token after login, the attacker gains full access to the victim's authenticated account.

To prevent this vulnerability:

1. The moment authentication succeeds, the Mendix Runtime immediately destroys and invalidates the anonymous session.
2. The runtime issues a brand-new authenticated session with a completely fresh session token (auth_xyz789).
3. The user's role transitions from Guest to their permanent enterprise User Roles.

The Shopping Cart Problem: Managing State Handover

Because the anonymous session is destroyed, any in-memory non-persistable entities (NPEs) or objects associated purely with the anonymous session object are discarded by the runtime's garbage collector. If an anonymous user spent 20 minutes building a shopping cart, an unhandled login transition will wipe out their cart!

Enterprise State Migration Pattern:

1. Persist the Session Key: When an anonymous user creates a cart or draft application, persist the record in the database with a unique tracking identifier (e.g., a generated UUID stored in a browser local storage key or tied to a staging token).
2. Custom Sign-In Microflow: Configure a custom sign-in action or utilize a Post-Login Microflow (configurable via the User Management or App Events modules):
   • Retrieve the pending cart record from the database using the tracking token.
   • Update the cart's association: change the owner reference from the anonymous identifier to the newly authenticated Administration.Account.
   • Commit the updated association to the database.
   • Refresh the client page to display the user's preserved items.

---

Security Boundaries on Public Pages & Microflows

Publicly accessible pages represent the exterior attack surface of your application exposed to automated scanners, penetration testers, and threat actors across the internet:

Microflow Security Guidelines for Guest Roles:

• Never Expose Internal Logic: Never grant the Guest role execution permissions on microflows containing sensitive internal business calculations, ERP integration calls, or batch operations.
• Parameter Manipulation Defense: When an anonymous user invokes a microflow from a button, always validate input parameters on the server side. Never trust client-side data.
• Data Retrieve Constraints: Data grids on public pages (e.g., ProductCatalog) must enforce explicit XPath constraints such as:

[IsActive = true() and IsPublished = true() and PublishDate <= '[%CurrentDateTime%]']

This prevents drafts, retired SKUs, or internal test products from leaking to the public web.

---

Restricting Anonymous File Uploads & DoS Defense

Allowing anonymous visitors to upload files—such as resumes on a job recruitment portal or photos on a public damage claim form—introduces severe security risks:

1. Primary Threat Vectors:

• Denial of Service (Storage Exhaustion): Malicious bots submitting thousands of 100 MB files to consume disk space and crash the database or cloud file storage.
• Malicious Executable Injection: Uploading executable scripts (.sh, .exe, .bat, or SVG files containing cross-site scripting JavaScript) disguised as images or documents.

2. Mandatory File Upload Defenses in Mendix:

Exam Trap: Relying on client-side browser file dialog filters (e.g., setting the file manager widget's accepted format property) does not provide security! Attackers can bypass client-side file pickers using automated HTTP POST requests (e.g., via Postman or curl). All file size, type, and content validations must execute server-side within a microflow.