Credentials or @ embedded in the URL

The URL contains a user:password@ section before the host, a legacy syntax that phishers use to make an address begin with a trusted name.

Do this: Do not open it; everything before the @ is decoration. Everything before the @ is ignored by the browser; only what follows it matters.
PassThe URL contains no embedded credentials.
HighThe URL embeds credentials or an @ that disguises the real host.

The fix, in one snippet

Example to adapt Where it really goes
https://[email protected]/login
                        ^ the actual host is evil.example

Illustrative values. Change the paths, hostnames and options to match your own site before using it.

The sections below explain what is tested, why it matters and the alternatives.

What we test

The checker parses the URL per the WHATWG standard and flags any userinfo component before the @, including one hidden with percent-encoding (%40). It shows the real host, which is whatever follows the @: in https://[email protected]/ the host is 203.0.113.7. It also notes credentials or tokens in the query string (?password=, ?token=) as information. Severity is high. Limits: some legacy intranet tools still use basic-auth URLs. Chrome drops the userinfo silently and navigates to the host, and blocks it for subresources, so the trick still takes you to the attacker's server; it just no longer sends the "credentials".

Why it matters

People read https://www.paypal.com and stop. The URL syntax defined in RFC 3986 treats everything before the @ as a username, so the browser goes to the host after it. Beyond deception, credentials in URLs leak into browser history, server logs, proxy logs and the Referer header of the next request. A message offering a "pre-authenticated" link with a password in it is, in itself, the tell: no legitimate service needs to send you a password inside a link. Recipients of email and SMS links are the audience, and the trick is most effective in clients that show the raw URL without highlighting the host.

How to fix it

Do not click. If you need to know where it goes, read the part after the @ and judge that host with the other findings. Report the message. Developers: never place credentials in a URL; use the Authorization header or a short-lived token in a POST body, and never log full URLs that might contain one. Related: raw IP hosts. Guides: how to spot phishing and password security.

Where this fits

Credentials or @ embedded in the URL is check 3 of 13 that the phishing url checker runs under url and phishing indicators, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.

Fix this one first

Above it in the same category sits Brand name used in a subdomain or path (high), where a well-known brand name appears in the subdomain or path of a URL whose registered domain is something else, for example paypal.com.secure-login.example. An attacker who has that does not need this, so it is the better use of the same hour.

What fixing this still leaves open

Credentials or @ embedded in the URL closes one route in. Immediately below it: Internationalised (punycode) domain, where the domain contains internationalised (non-ASCII) characters encoded as punycode (xn--), which can make a lookalike address display as a trusted brand; Lookalike of a well-known brand domain, where the registered domain closely resembles a well-known brand's domain through a typo, an inserted character, a swapped letter or a plausible variant, but is not it; Domain registered very recently, where the domain was registered very recently, which is typical of phishing infrastructure that is created, used for days and discarded.

Prompt for an AI Hand this check to an assistant Sign in to copy it
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.

Finding: Credentials or @ embedded in the URL (high severity)
Scanner check id: url-credentials-embedded
18 more lines, including the evidence and the exact fix

The rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.

Sign in with Google

Signing in is free and takes one click. We store your email address and nothing else.

References

  1. RFC 3986 section 3.2.1: User Information
  2. WHATWG URL Standard
  3. MDN: HTTP authentication (credentials in the URL)

Related guides