10
Views
1
Comments
Concern: Public Server Action Exposing User Data in MFA/Login Flow
Question
Application Type
Reactive
Service Studio Version
11.55.36 (Build 64309)
Platform Version
11.37.0 (Build 45622)

Hi everyone,

We are working on an MFA login flow and have noticed a serious concern with how data is exposed to the client.

Here’s the current flow:

  1. The user enters their email on the login screen.

  2. A Data Action calls a server action (GetUserInfoByEmail) to retrieve details.

  3. The response with user details is visible in the browser DevTools → Network tab.

This raises some important questions:

  • Since the server action is public (pre-authentication), does this mean anyone can call it directly?

  • Shouldn’t it be possible to perform login/MFA without exposing any user information at all to the client before authentication?

  • How do we prevent attackers from using this to enumerate valid users or gain internal details?

  • What are the best practices in OutSystems for handling login/MFA flows without leaking information to the client?

  • Is there a recommended way to structure Data Actions so they don’t reveal unnecessary data in network responses?

At the moment, the biggest issue is that user information is exposed too easily in the client during the login process, whereas ideally no sensitive information should be exposed before the user is authenticated.

Has anyone faced this challenge, and how did you handle it?

Thanks in advance for your advice!

Mohamed Zubair Ahmed Rizwan,
0768689103


LoginPleyel.png
2019-11-11 17-10-24
Manish Jawla
 
MVP

Hi @Mohamed Zubair Ahmed Rizwan ,

For scenarios involving custom MFA you can use below approach:

  • Generate Random Token

    • Create a random token of 50–100 characters before navigating to the MFA screen.

  • Associate with User

    • Store the generated token in db against the specific user who is attempting authentication.

  • Pass as Input Parameter

    • Use this token as an input parameter when rendering the MFA page to that you can validate it against the same user.

  • Ensure Security

    • Since the token is randomly generated for each request, it provides strong security for the anonymous MFA page.

  • Clean Up After Authentication

    • Once authentication is successfully completed, delete the token from the database to prevent reuse.

Regards,

Manish Jawla

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.