Is your customer data protected? Three initial checks

A sign-in screen is not enough to check who can see your data. Three simple trials on your own app, followed by the evidence to request from its builder.

Your app asks for a password, but does each user see only the information intended for them? Here are three initial checks to perform on your own app with fictional data. They may reveal a visible problem; they do not replace a technical security review.

Understand what you are checking

Signing in identifies a person. Access permissions then decide what they may view or change. A signed-in customer should not obtain another customer’s contact details simply because they know a page address.

OWASP, an organisation specialising in application security, recommends checking permissions on every request, on the server or in appropriate infrastructure. Hiding a button on screen is therefore not enough: the request itself must be refused when it is not authorised.

Try without signing in

Open your app in a private browsing window without signing in. Try the addresses of your usual work pages. A public page may be normal; a confidential customer list should not appear.

When possible, do this with a test version containing fictional information. Record the page, action and observed result. You will have a specific example to give the person maintaining the app.

Compare two test accounts

Create two accounts you control with comparable roles. In each, add a recognisable fictional request. Sign into the first account and check that it cannot find the second account’s private request in lists or searches.

Also try opening that request’s address from the other account, if your app uses such addresses. The expected result depends on the chosen rules: a manager may have access to several records, while a customer sees only their own.

Check downloaded files

If an ordinary account can export data, open its export file. It should contain only information that account is allowed to obtain. Have attachment access checked too, because the rules concern more than pages and tables.

Correct results in these trials do not prove that every access path is protected. Ask which technical controls and tests cover the other cases. Our guide to risks in AI-created apps helps prepare this discussion.

If you see information that should be private

Record what happens without sharing or downloading more data. Notify the responsible person so they can restrict the affected access and assess the extent of the problem. After the fix, repeat the trial that failed.

With Maestro, describe from the start who may see and change each piece of information, then have the result checked. Approval stages do not provide a security guarantee. Your data also explains exchanges with assistants during construction.