Security Review of an Internal Web App Where the Login Screen Was Not Enough

An internal staff support web app had a login screen and an admin reply feature. It appeared to separate users. However, this did not prove that the server restricted access.

My task was to review the public deployment without source code. I needed to find where authentication and access control took place.

The full app loaded even when the request had no login details. It did not move to a separate login page. The browser code checked login status and admin status. It also contained server function names linked to message storage and admin replies.

The problem I owned

The web app handled staff questions and admin replies. A login screen alone could not prove that sensitive content was protected.

The main questions were clear. Could an anonymous user reach the deployed app? Did the server also check the difference between users and admins?

Facts and limits I checked

The server returned the full app HTML without cookies or login details. The browser code handled login, roles, and admin status. I also found several points where the browser called server functions.

The code repeatedly included text related to staff information. This made it hard to treat the app as a simple public page.

However, this review used only external observation because I had no source code. I did not run server functions anonymously to test whether they returned data. I did not extract any real data.

I also could not confirm which account ran or owned the app. I did not have access to its deployment settings.

The choice I made

I limited the review to anonymous responses and code sent to the browser. I did not prove the risk by trying to access real data.

I recorded confirmed facts separately from concerns caused by the design.

Anonymous access and browser-side role checks were confirmed issues. Server function permissions and actual data returns remained open questions.

What I actually did

I checked responses to requests without login details. I reviewed how much of the app loaded before authentication.

In the browser code, I found checks for login status and admin status. I also found calls that stored user messages and admin replies.

Based on these findings, I suggested limiting deployment access to signed-in users within the organization. I also suggested checking user and admin permissions on the server.

Moving ownership of the scripts and data to an organization-managed account remained a separate task.

Confirmed results and remaining work

I confirmed that anonymous users received the full app. The login and admin checks depended on browser code.

For this reason, the current screen alone could not prove that access was controlled.

There is still no evidence that the deployment settings have changed. Anonymous access to server functions has not been tested.

It is also unclear whether the staff-related text connects to real data queries. The owners of the app and its data are still unknown.

The next review must check the source code or deployment settings. It should confirm the account that runs the app and its access permissions.