// TECHNOLOGIES / AMAZON COGNITO

Amazon Cognito

Amazon Cognito, without flagging what is public.

Every correct Amplify front end ships a userPoolId, an app client id, an identityPoolId and a region — and Cognito permits unauthenticated guest identities by design. A scanner that reports any of that is unusable on AWS. This detector is mostly guard: it confirms the integration from two independent signals, then reports only what is genuinely wrong — a credential that should never have reached the browser, and an authorization endpoint that accepts a redirect URI it should have rejected.

The dashboard blind-spot

// why an external scan matters

// THE DASHBOARD SHOWS (WHAT YOU CONFIGURED)

Your user pool and identity pool configuration, app client settings, callback URLs, token lifetimes and guest role policy — as configured in the AWS console.

// IT CAN'T SEE (NEWSCAN DOES)

That confidential-client credentials or a long-lived AWS access key were compiled into your browser bundle, that an aws-exports.js in your web root carries a secret alongside the public identifiers, and that your authorization endpoint issues a code to an unregistered destination.

What NewScan records

// proven, then reproduced

Client secret or AWS credential in client code

CRITICAL

A Cognito client_secret or an AKIA key readable in the browser bundle beside confirmed Cognito configuration. A browser app client is a public client and is not issued a secret — which is exactly why its presence is the finding.

Cognito configuration exposed with credential material

HIGH

An Amplify config served anonymously carrying a secret. A config holding only the public pool and client identifiers is correct, and is what every Amplify app ships.

Unregistered redirect URI accepted

HIGH

The application's own authorization endpoint issues a code or token to a canary host.

What is never flagged

// the false-positive contract

A scanner earns its place by what it stays quiet about. These are guarantees, each one asserted by a test that fails the build if it regresses — not best-effort tuning.

userPoolId, app client id, identityPoolId, issuer, JWKS

Public integration metadata. Recorded as evidence, never as a finding.

The hosted login domain

*.auth.<region>.amazoncognito.com is public by design.

Open self-sign-up

A product decision, not a flaw.

A guest identity from GetId

Cognito permits unauthenticated identities for legitimate guest access. Credential issuance alone is silent — it matters only alongside a proven excessive permission.

How it's proved

// training/tech/amazon-cognito

A Cognito-integrated app and a control shipping the identical public pool, client and identity-pool ids, hosted domain, open sign-up and GetId guest access. The control must score zero.

// FINGERPRINT FIRST

The check is silent unless the product is confirmed by two independent signals. A single, spoofable marker confirms nothing.

// REPRODUCE BEFORE RECORD

Every finding is re-run by our own detector before it is written down. A model's self-assessment is discarded, not merged.

// SEVERITY THAT MAPS

One calibrated severity per finding, translated into PCI DSS, SOC 2, ISO 27001, HITRUST, HIPAA and NIST 800-53 ratings with remediation SLAs.

Run it against your own Amazon Cognito

NewScan is free and self-hosted — bring your own key. Every check on this page runs in the deterministic floor with no model and no provider key at all, so scanning your own Amazon Cognito surface is local to you and depends on no hosted resource.