Stop Sign-In From Sending Customers to the Wrong Website

A customer taps “Sign in with Google,” leaves your app briefly, and expects to return to the dashboard, checkout, or page they were using. Your app and the sign-in service need a saved return address to make that happen. If the saved rule accepts too many addresses, a misleading message can start on your real app and finish on a convincing imitation. The customer may believe the imitation is still part of your service and enter a password, payment information, or an access code there.

The simple rule is to return people only to complete page addresses that you operate. The technical name for a return address is a redirect URL. The technical name for the common system that lets someone enter through Google, Apple, or another company is OAuth. The sign-in company compares the requested return address with the destinations you approved. This approval may be configured in your AI-built app, in the sign-in company’s control panel, or in both places. A safe review therefore checks every location instead of trusting one screen.

Broad rules often begin as a shortcut. During building, you may use a temporary preview, a personal test site, and the final public website. It can seem easier to approve every address that resembles your app’s name. The problem is that a broad rule may also approve a forgotten page or a website section controlled by somebody else. Customers rarely inspect every character after signing in, so even a small difference can make an imitation difficult to notice.

Use the smallest possible list of complete addresses: the correct website name, the secure “https” beginning, and the exact page when the sign-in company supports it. Developers call this an allowlist, meaning a written list of destinations that are accepted while all others are rejected. Developers call an asterisk or similar broad matching symbol a wildcard. Remove wildcards, old preview addresses, retired websites, and unused testing entries. If testing still needs its own destinations, keep them separate from the public app and record who controls each one.

The main sign-in button is only one journey. A person may return after creating an account, confirming an email address, changing a forgotten password, connecting a calendar, or choosing Google, Apple, or another company. Each journey can use a separate saved destination. Fixing the ordinary sign-in journey does not automatically fix the others. A forgotten setting is especially confusing because the customer may arrive from a genuine email and assume that every page opened afterward is also genuine.

Test these journeys as a normal customer on the public version of your app. Use accounts and email addresses that you control. Check the full address shown by the browser after every step, not only the page design or app name. Record the expected final page and confirm that an unexpected destination is refused. The technical name for this refusal check is a negative test: you deliberately try an unapproved but harmless address and confirm that the system blocks it. Never use somebody else’s website or account for this test.

AI-built apps can change quickly. You may add a custom website address, move away from a preview, rename the app, or offer another sign-in choice. Each change can introduce a new return destination. Add one only when you can explain why customers need it, who controls it, and whether it belongs to the public app or testing. Remove temporary entries when their work ends. Keep a short record so the next person does not have to guess why an unfamiliar address remains approved.

Review the list after every account-related change and on a regular schedule. Give one person responsibility for confirming each destination and testing the important journeys. VibeCodeWall checks the public app from the outside; it does not see private code. It can help you observe what the public app exposes and watch for important changes over time. It cannot replace a direct review of the saved destinations inside each sign-in company’s control panel, because those settings may not be visible from the public app.