Make sure a security check targets your app, not someone else’s

Your AI builder may have given you a temporary address while you were creating the app. Later, you may have connected a branded address for customers while keeping the temporary version available. Both pages can look almost identical. If you request a security check for the temporary version, the report may say nothing about the app where customers log in, enter customer information, or make payments. The useful first step is therefore identifying one exact customer-facing address.

Open a private browser window and type the address shown in your emails, advertisements, invoices, or social profiles. A private window helps you see the page more like a new visitor would. Wait for it to load, then copy the complete address from the browser bar. The technical name for the recognizable main part, such as example.com, is a domain. Words before it, such as www or shop, can lead to a different destination, so record them too.

Imagine that anyone could enter your shop’s address into a service and request powerful changes or claim its reports. A responsible service first asks the requester to make a small, specific change in a place controlled by the owner. It then looks for that change. If the expected proof appears, the service has reasonable evidence that the account setting up the connection controls that web address. The technical name for this process is domain ownership verification.

This proof has a narrow purpose. It does not show that every page is safe, that every customer record is protected, or that the person will always control the address. It also does not hand the checking service the private building instructions for your app. Developers call those instructions source code. Ownership verification only connects an account with control of a particular public address at that time, helping prevent an accidental or unauthorized check of another person’s site.

A service may ask you to add a short text entry where your web address is managed. The internet uses a directory-like system to send visitors to the correct place. The technical name is the Domain Name System, usually shortened to DNS. A specially requested DNS entry can show that you control the address because an unrelated visitor normally cannot add it. Another service may instead ask for a small verification file on the public app. Follow only the method displayed by that service.

The supplied verification value is setup information, not a request for a powerful account detail. Never substitute the password for your domain account, a payment key, an access code, or customer information. Do not paste those items into an AI conversation or a file visitors can download. If another person manages the domain account, send them the requested entry’s type, name, and value. Ask them to add it through their normal approved process and confirm the result without sharing their login password.

Small differences can matter. example.com, www.example.com, shop.example.com, and example.app may open different versions or send visitors elsewhere. Test each known address in a private browser window and watch the browser bar after the page finishes loading. When one address automatically sends a visitor to another, the technical name is a redirect. Record both the starting address and the final destination instead of assuming that they represent the same setup.

This review also protects ordinary customer journeys. A payment confirmation could send buyers to an old preview, or a login link could return them to a test version. That can create confusion even when the payment or login itself worked. Do not immediately delete an old address: emails, bookmarks, payment settings, or partner services may still use it. First identify those uses, then ask your AI builder or developer to plan a safe move to the intended address.

When the service accepts the proof, record the verified address, the connected account, the date, and the person who receives notices. Then confirm that the check is aimed at the final customer-facing destination. Repeat this review after changing the domain, moving the app to another hosting provider, or changing login and payment return addresses. A setup that was correct last month can quietly become outdated even when the old site still opens.

VibeCodeWall’s free checks examine what the public can reach at the submitted app address. They do not read private source code, and proving ownership does not establish that the whole app is safe. Continuous Pro monitoring is separate: it must be activated and uses the technologies and versions actually listed in the app’s inventory. That inventory is the recorded list of the building tools and versions the app uses. Missing items limit coverage, so update the list when your AI builder changes them.