Google marked the site with NextAuth as malicious

[Edymov]

Question 💬

After moving to a new domen, google site security check, it mark a site malicious.
As i understand, google marks nextAuth pages as dangerous.

Can NextAuth realy affects google to mark the site dangerous?

How to reproduce ☕️

Contributing 🙌🏽

Yes, I am willing to help answer this question in a PR

[Crazypersonalph]

Somebody has reported your domain as malicious to google, it is not a problem with authjs.
It might be that the previous owner of this domain might have been malicious with it.
You have to get this sorted out with your domain registrar and Google.

[Crazypersonalph]

Also it looks like you might have another third-party package causing this issue

Could you please send your package.json?

[bmelton]

I can confirm that it triggers the deceptive warning message with a package.json this minimalist.
I think 'malicious package' is a red herring.

https://gist.github.com/bmelton/0d34af51b198f2a86bebed8a79ecfe59

[balazsorban44]

This is not caused by the library.

[fullnelson14]

Is there any other direction or guidance on this? I am in the same boat. It is fine if this is not caused by the library. However, I still need to find a way to solve the problem: google is recognizing my site as dangerous, which is not the case.

[Crazypersonalph]

It's not an issue with NextAuthjs

Check the libraries you are using in your project, whether you installed the right packages, whether your computer is infected, etc.

Thanks

[fullnelson14]

I have scanned the website using quttera.com - no problems. Here's my package.json:

{
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "prisma generate & next build",
    "start": "next start"
  },
  "dependencies": {
    "@cloudinary/react": "^1.11.2",
    "@cloudinary/url-gen": "^1.11.0",
    "@dhaiwat10/react-link-preview": "^1.15.0",
    "@dnd-kit/core": "^6.0.8",
    "@dnd-kit/sortable": "^7.0.2",
    "@dnd-kit/utilities": "^3.2.1",
    "@fortawesome/fontawesome-svg-core": "^6.4.0",
    "@fortawesome/free-regular-svg-icons": "^6.4.0",
    "@fortawesome/free-solid-svg-icons": "^6.4.0",
    "@fortawesome/react-fontawesome": "^0.2.0",
    "@next-auth/prisma-adapter": "^1.0.5",
    "@prisma/client": "^5.1.1",
    "@ramonak/react-progress-bar": "^5.0.3",
    "@tailwindcss/typography": "^0.5.9",
    "axios": "^1.2.6",
    "moment": "^2.29.4",
    "next": "latest",
    "next-auth": "^4.19.2",
    "next-cloudinary": "^4.16.3",
    "nextjs-google-analytics": "^2.3.3",
    "react": "18.2.0",
    "react-datepicker": "^4.16.0",
    "react-datetime-picker": "^5.3.0",
    "react-dom": "18.2.0",
    "react-markdown": "^8.0.5",
    "react-player": "^2.11.2",
    "react-qr-code": "^2.0.11",
    "react-tiny-link": "^3.6.1",
    "react-youtube": "^10.1.0",
    "swr": "^2.0.4"
  },
  "devDependencies": {
    "@types/node": "18.11.3",
    "@types/react": "18.0.21",
    "@types/react-dom": "18.0.6",
    "autoprefixer": "^10.4.12",
    "postcss": "^8.4.18",
    "prisma": "^5.1.1",
    "tailwindcss": "^3.2.4",
    "typescript": "4.9.4"
  }
}

I have scanned my computer with Windows Security - no problems there. I'm not exactly a pro in detecting malware, so some help or resources would be appreciated. What am I looking for exactly?

[Crazypersonalph]

It might be that somebody reported your domain as malicious to Google or some other cybersecurity company, and now it's being flagged; You would need to contact Google directly about that.

[fullnelson14]

Ok, it looks to be working. I filled out the form here: https://safebrowsing.google.com/safebrowsing/report_error/?sjid=16248749009624881881-NA&hl=en

And I guess that worked? Thanks for the tips.

[chiefdeals]

It's not an issue with NextAuthjs

Check the libraries you are using in your project, whether you installed the right packages, whether your computer is infected, etc.

Thanks

Mine was working fine until adding next-auth, that's all I've added on that push. Literally the only difference. This shows up on two different hostnames, on two different servers, on two different sides of the united states. the only thing they have in common is codebase (they dont even talk to eachother), they both experienced this problem only after implementing oauth (github). they both point to /api/auth/signin (source: Google Search Console -> Security & Manual Actions -> issues detected:

Deceptive pages
Description
These pages attempt to trick users into doing something dangerous, such as installing unwanted software or revealing personal information. Learn more
Sample URLs
https://xxx/api/auth/signin
https://xxx/api/auth/signin/

// .../api/auth/[...nextauth].ts

import NextAuth from "next-auth"
import GithubProvider from "next-auth/providers/github"

export const authOptions = {
  providers: [
    GithubProvider({
      clientId: process.env.GITHUB_ID,
      clientSecret: process.env.GITHUB_SECRET,
    }),
  ],
}

export default NextAuth(authOptions)

There was nothing custom about the implementation, followed vanilla to the T

[feg624]

I'm on the same boat as well. I created the app domain just today, and published a blank NextJS app. However, when I included the NextAuth library (to get authenticated with Keycloak in my case), the domain got marked as Dangerous.

[salilponde]

Same here. Had the issue on two domains on brand new servers. So unlikely to be malware.

[salilponde]

I added my site to Google Search Console and it showed the warning there. I clicked the button to say I fixed the issue and mentioned there is no malware on my site. In 2 days Google confirmed and removed the false warning.

[bmelton]

I have done the same thing, and it worked.

It's curious that my domain has no history (has never been registered before according to whois), is only 8 days old, has never been publicized at all, and yet somehow it was in Google's naughty list.

Either way, thanks for the tip @salilponde -- worked a charm.

[salilponde]

Yeah, for some reason Google doesn't like the api/auth/** in next-auth. It flags this path but my custom login page at /login wasn't flagged.

[jennnx]

Can we re-convert this discussion into an issue?

Is there a mod that can do this?

As @bmelton and many others said this issue is reproducible. Same happened to me.
Fresh project, fresh deploy to Vercel, fresh domain from porkbun (less than a week old).
Every route on the site works perfectly fine, but just the /api/auth/[...] wildcard domains trigger the full-screen red Google warning.

Meanwhile as @salilponde said it looks like your work-around options are:

1. Add your site to Google Search Console for a manual Google review
2. Do not use the next-auth generated sites for auth. Instead, manually create your own signin routes.

FYI I'm on Next 14.0.1 and next-auth 5.0.0.-beta.3

[VicSmithVercel]

Any docs you can point me to for custom signin routes?

[mrzarkovic]

I'm also facing this issue

[chiefdeals]

Mine was a configuration issue. I’d imagine most of these are. There’s too much dependent on the way your routes and subsequent callback url is set up with your auth0 provider. Mine, more specifically, was making sure my callback url matched the entry point and route to my app Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: J ***@***.***> Sent: Thursday, November 9, 2023 2:17:33 PM To: nextauthjs/next-auth ***@***.***> Cc: chiefdeals ***@***.***>; Comment ***@***.***> Subject: Re: [nextauthjs/next-auth] Google marked the site with NextAuth as malicious (Discussion #7238) Can we re-convert this discussion into an issue? Is there a mod that can do this? As @bmelton<https://github.com/bmelton> and many others said this issue is reproducible. Same happened to me. Fresh project, fresh deploy to Vercel, fresh domain from porkbun (less than a week old). Every route on the site works perfectly fine, but just the /api/auth/[...] wildcare domains trigger the full-screen red Google warning. — Reply to this email directly, view it on GitHub<#7238 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A6G4PMHBN5TFNJ22SZZ4KJDYDVI73AVCNFSM6AAAAAA3OMDZGGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMRXGU3DI>. You are receiving this because you commented.Message ID: ***@***.***>

[VicSmithVercel]

Having the same issue across a second domain.
Verifying in google search console as some others have.
Can someone post docs on doing custom sign-in routes?

[olafur164]

Has anyone here figured this out? We are launching a new product and we just got it out on live but getting Dangerous site on all next auth routes. @VicSmithVercel did you manage t o set a custom routes for auth and get it to fix itself like that?

[bmelton]

Yes. It's not an issue with Next-Auth, or at least if it is, it can be fixed without fixing anything relating to Next-Auth.

To fix it, add your site to Google Search Console Tools (formerly Webmaster Tools)
It will complain that your site is untrusted, and give you a link to click to contest that decision. I followed that link and filled out the form, and then Google sent me an email saying I was right and they were wrong within a couple of days I think..

[adymo]

Just to add two more data points. We had the same problem with two apps using NextAuth on two different domains. Something in the way NextAuth works triggers this. My guess is Chrome detects it. With our second app deployment, we reproduced the issue ourselves the same day. No chance anyone would have the time to report phishing.

Here's what the user sees in the browser when they go to /api/auth:

[giovanniscalar]

I have the same problem. Is there any updates on this or have you found a solution?

[adymo]

We submitted a review request in Google Search Console and they cleared it

[sideBeaze]

hi, did you already have google console set up for your site? Mine has been fine for weeks and then once i added next-auth email provider i started getting this warning trying to auth on my phone. However i then went on to register with google search console and it's just saying no issues, will it take a few days to come up?

[ericf1]

Hi I was also facing this issue and I was able to resolve it by correcting my domain name.

You may have like the word Spotify in your domain name which makes Google think you are impersonating the company.

[laurencefass]

This looks like a chrome issue Im not getting any such error in Edge.

[marcosdayanm]

Indeed, it looks like it's a Chrome security feature

[BrofessorNFT]

Hi everyone, had the same issue, fixed it with setting correct cname record to my www domain on vercels. When you add a custom domain there they only tell to add an A record, but to set up www. domain you need to also set up a cname record

[sreyemnayr]

I encountered this issue as well (brand new domain, site worked fine with Vercel subdomain).
Once I switched to the new domain – which was set up correctly with a CNAME record for www – I encountered the "dangerous site" warning. There's pretty much a 0% chance that anyone "reported the site for phishing" and the Google console didn't have any reports when I clicked that link.
I think that Google is auto-flagging the default auth url schemes. Not sure if anyone here has some pull to have that investigated/corrected.

I was able to mitigate it by doing the following:
Rename the the directory for the api route to nextauth (instead of auth) and setting the baseUrl and basePath in the provider:

<SessionProvider session={session} baseUrl={baseUrl} basePath={`/api/nextauth`}>
  {children}
</SessionProvider>

I also added the basePath to my NextAuthConfig object:

const authConfig: NextAuthConfig = {
  ...
  basePath: "/api/nextauth",
}
export const { auth, handlers, signIn, signOut } = NextAuth(authConfig)  

I'm not actually sure which of these fixed it, and don't have time to sort it out at the moment. Hope it helps!

[undesicimo]

It seems api/auth/signin (the default signin page)is flagged by google and when chrome additional protection is on, it prompts with the warning. Adding a custom login page solves the issue because i wont have to redirect to api/auth/sign. In this sense @sreyemnayr solution should work as well

[AminSajedian]

Thanks.

As you mentioned, creating a custom login page is a good solution to avoid the issue with the default NextAuth api/auth/signin route and callbackUrl. By implementing a custom login page, you have more control over the page’s security and behavior, which can help prevent Google from flagging it.

Create a Custom Login Page for NextAuth:

Create a Custom Login Page:
You can create a custom login page in your Next.js app by using signIn from NextAuth and passing the user credentials.

Example: Custom Login Page (pages/login.js):

import { useState } from "react";
import { signIn } from "next-auth/react";
import { useRouter } from "next/router";

export default function Login() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [error, setError] = useState(null);
  const router = useRouter();

  const handleSubmit = async (e) => {
    e.preventDefault();
    const res = await signIn("credentials", {
      redirect: false, // Prevent redirect to default page
      email,
      password,
    });

    if (res.ok) {
      router.push("/"); // Redirect to homepage or dashboard
    } else {
      setError("Invalid login credentials");
    }
  };

  return (
    <div className="container mx-auto">
      <h1>Login</h1>
      <form onSubmit={handleSubmit}>
        <div>
          <label>Email</label>
          <input
            type="email"
            value={email}
            onChange={(e) => setEmail(e.target.value)}
          />
        </div>
        <div>
          <label>Password</label>
          <input
            type="password"
            value={password}
            onChange={(e) => setPassword(e.target.value)}
          />
        </div>
        {error && <p style={{ color: "red" }}>{error}</p>}
        <button type="submit">Login</button>
      </form>
    </div>
  );
}

Update the Sign-in Redirection:
You’ll also need to update your authOptions configuration in [...nextauth].js to point to the custom login page.

Example: Updating NextAuth Config:

In pages/api/auth/[...nextauth].js, update the pages configuration to define your custom login page:

export const authOptions = {
  ...
  
  pages: {
    signIn: "/login", // Points to your custom login page
  },
  ...
};

With this, users will be redirected to /login instead of the default api/auth/signin page.

Final Thoughts:

Moving to a custom login page will likely solve the "Dangerous Site" warning issue and allow you to fully customize the user login experience. Let me know if you need help with any part of this implementation!

[marcosdayanm]

I have the same issue, I implemented my authentication based on https://next-auth.js.org/getting-started/example documentation, the nextauth v4, I have the service on Cloud Run by GCP, it worked perfectly, but since I added a domain to the service, I have this same issue. I am having problems following @sreyemnayr fixes because my nextAuth implementation is slightly different:

app/api/auth/[...nextauth]/route.ts

import { PrismaAdapter } from "@next-auth/prisma-adapter";
import NextAuth, { AuthOptions } from "next-auth";
import GoogleProvider from "next-auth/providers/google";
import prisma from "@/prisma/prisma";

const authOptions: AuthOptions = {
  session: {
    strategy: "jwt",
    maxAge: 1 * 60 * 60, 
  },
  adapter: PrismaAdapter(prisma),
  providers: [
    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
      profile(profile) {
        return {
          id: profile.sub,
          name: profile.name,
          email: profile.email,
          image: profile.picture,
          roleLevel: 1,
          emailVerified: null,
          phoneNumber: null,
          birthDate: null,
          curp: null,
          addressId: null,
          proofOfAddress: null,
          cloudStorageImageURL: null,
          createdAt: new Date(),
          updatedAt: new Date(),
          isActive: true,
        };
      },
    }),
  ],

  callbacks: {
    async jwt({ token, user, account }) {
      if (account && user) {
        token.id = user.id;
        token.roleLevel = (user as any).roleLevel;
      }
      return token;
    },
    async session({ session, token }) {
      session.user.roleLevel = token.roleLevel ?? 0;
      session.user.id = token.id;
      return session;
    },
  },
};

const handler = NextAuth(authOptions);

export { handler as GET, handler as POST };

Does anyone had my same imlementation or have a clue on how can I solve the issue?

[sreyemnayr]

I had to change the auth directory’s name. The content of route.ts shouldn’t matter.

…

On Tue, Aug 13, 2024 at 7:37 PM Marcos Dayan Mann ***@***.***> wrote: I have the same issue, I implemented my authentication based on https://next-auth.js.org/getting-started/example documentation, the nextauth v4, I have the service on Cloud Run by GCP, it worked perfectly, but since I added a domain to the service, I have this same issue. I am having problems following @sreyemnayr <https://github.com/sreyemnayr> fixes because my nextAuth implementation is slightly different: app/api/auth/[...nextauth]/route.ts `import { PrismaAdapter } from ***@***.***/prisma-adapter"; import NextAuth, { AuthOptions } from "next-auth"; import GoogleProvider from "next-auth/providers/google"; import prisma from "@/prisma/prisma"; const authOptions: AuthOptions = { session: { strategy: "jwt", maxAge: 1 * 60 * 60, }, adapter: PrismaAdapter(prisma), providers: [ GoogleProvider({ clientId: process.env.GOOGLE_CLIENT_ID!, clientSecret: process.env.GOOGLE_CLIENT_SECRET!, profile(profile) { return { id: profile.sub, name: profile.name, email: profile.email, image: profile.picture, roleLevel: 1, emailVerified: null, phoneNumber: null, birthDate: null, curp: null, addressId: null, proofOfAddress: null, cloudStorageImageURL: null, createdAt: new Date(), updatedAt: new Date(), isActive: true, }; }, }), ], callbacks: { async jwt({ token, user, account }) { if (account && user) { token.id = user.id; token.roleLevel = (user as any).roleLevel; } return token; }, async session({ session, token }) { session.user.roleLevel = token.roleLevel ?? 0; session.user.id = token.id; return session; }, }, }; const handler = NextAuth(authOptions); export { handler as GET, handler as POST }; ` Does anyone had my same imlementation or have a clue on how can I solve the issue? — Reply to this email directly, view it on GitHub <#7238 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBJQTSFRA7ZOFBFSTSXKXTZRKREXAVCNFSM6AAAAAA3OMDZGGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMZTGE2DINI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[marcosdayanm]

Thank you! But seems like I cannot change this setting basePath: "/api/nextauth" , on my authOptions it isn't recognized by the AuthOptions type. And since I cannot do this, NextAuth is trying to redirect me to the wrong URL, not the changed one resulting in an error

[sreyemnayr]

For me, I wasn’t using a login page at all, the connect button was baked into the home page. It was the callback url from the Spotify connect that was getting flagged. Anyway, do whatever works best until Google decides to stop being ridiculous with their rules!

…

On Tue, Sep 10, 2024 at 12:50 PM Amin Sajedian ***@***.***> wrote: Thanks. As you mentioned, *creating a custom login page* is a good solution to avoid the issue with the default NextAuth api/auth/signin route. By implementing a custom login page, you have more control over the page’s security and behavior, which can help prevent Google from flagging it. Create a Custom Login Page for NextAuth: *Create a Custom Login Page*: You can create a custom login page in your Next.js app by using signIn from NextAuth and passing the user credentials. Example: Custom Login Page (pages/login.js): import { useState } from "react";import { signIn } from "next-auth/react";import { useRouter } from "next/router"; export default function Login() { const [email, setEmail] = useState(""); const [password, setPassword] = useState(""); const [error, setError] = useState(null); const router = useRouter(); const handleSubmit = async (e) => { e.preventDefault(); const res = await signIn("credentials", { redirect: false, // Prevent redirect to default page email, password, }); if (res.ok) { router.push("/"); // Redirect to homepage or dashboard } else { setError("Invalid login credentials"); } }; return ( <div className="container mx-auto"> <h1>Login</h1> <form onSubmit={handleSubmit}> <div> <label>Email</label> <input type="email" value={email} onChange={(e) => setEmail(e.target.value)} /> </div> <div> <label>Password</label> <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} /> </div> {error && <p style={{ color: "red" }}>{error}</p>} <button type="submit">Login</button> </form> </div> );} *Update the Sign-in Redirection*: You’ll also need to update your authOptions configuration in [...nextauth].js to point to the custom login page. Example: Updating NextAuth Config: In pages/api/auth/[...nextauth].js, update the pages configuration to define your custom login page: export const authOptions = { ... pages: { signIn: "/login", // Points to your custom login page }, ...}; With this, users will be redirected to /login instead of the default api/auth/signin page. Final Thoughts: Moving to a custom login page will likely solve the "Dangerous Site" warning issue and allow you to fully customize the user login experience. Let me know if you need help with any part of this implementation! — Reply to this email directly, view it on GitHub <#7238 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBJQTRCZ34WRWSU7GVY3WTZV4WOJAVCNFSM6AAAAAA3OMDZGGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRQGU3TMNQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[alexkarpovich]

In my case I change default auth api folder (as suggested above) and call it /api/identity and it partially work but when I open root page it anyway redirects me to the default /api/auth/signin, after investigation I noticed this line with hardcoded basePath for auth.

To fix it I've rewritten useSession hook and it started working but I assume that it might not be necessary if we pass session object to SessionProvider.

[NJneeraj]

Same warning on my website after adding next-auth to it.

[marcosdayanm]

I got it solved entering to https://search.google.com/search-console/ and in the security issues section, writing how your problem got originated and exlaining the redirect is made by Next.js. Algo, I provided code snippets of what I was doing