https://crumbcraft-bakery.example
Deep scan of crumbcraft-bakery.example found 8 issues across headers, cookies, exposed files, and email authentication. The most urgent problems are an exposed .env file and a missing Content Security Policy. Overall security posture is Fair.
This measures publicly observable configuration and exposure only. It is not a full vulnerability assessment: authorization, business logic, and dependency issues were not tested.
Findings
Confirmed issues (4)
We observed each of these in an actual response from your site. Evidence is attached to every item.
The site's .env file is served over the public web. It appears to contain database credentials and an API secret, meaning anyone can read production secrets.
What to do: Remove the .env file from the deployed public directory immediately, block dotfiles at the web server or CDN level, and rotate every credential it contained (database password, API keys).
The crumbcraft_session cookie is set without HttpOnly or Secure, so JavaScript can read it (enabling session theft via XSS) and it can travel over plain HTTP.
What to do: Set the session cookie with Secure, HttpOnly, and SameSite=Lax (or Strict) attributes in the auth code.
The /.git/HEAD file is publicly readable, indicating the whole Git history may be downloadable — including past secrets and removed code.
What to do: Configure the web server to return 403 for any path under /.git, and remove the .git directory from production deployments.
JavaScript source maps are publicly accessible, exposing the original unminified source code and internal comments to anyone.
What to do: Disable source-map generation for production builds, or restrict access to .map files to internal tooling only.
Hardening suggestions (4)
A missing or weak defensive layer. These are worth fixing, but on their own they do not prove an exploitable vulnerability.
The site sends no Content-Security-Policy header, so any injected script (for example via a stored XSS bug in the order-comments feature) can run unrestricted.
What to do: Add a Content-Security-Policy header. Start with default-src 'self' plus the exact script/style hosts the site needs, then tighten over time.
No X-Frame-Options header and no frame-ancestors directive, so the site can be embedded in a malicious page that tricks users into clicking hidden buttons.
What to do: Send X-Frame-Options: DENY (or SAMEORIGIN) on all responses, or add frame-ancestors 'none' to the Content Security Policy.
crumbcraft-bakery.example has no SPF record, so attackers can send email that appears to come from the bakery (order scams, phishing) without being flagged.
What to do: Publish a TXT record such as v=spf1 include:_spf.your-mail-provider.com -all, and add DKIM and DMARC for full protection.
The Strict-Transport-Security header is present but with a max-age of only 86400 (one day), giving little lasting downgrade protection.
What to do: Raise max-age to at least 31536000 (one year) and add includeSubDomains once all subdomains support HTTPS.
Every check we can run, and whether it ran on this target.
- Fetch homepage and follow redirects
- HTTPS enforcement and transport
- Security response headers
- Cookie flags and prefixes
- Software / framework disclosure in HTML
- Secret patterns in HTML
- Subresource integrity on third-party scripts
- Mixed HTTP content on HTTPS pages
- CORS policy
- Allowed HTTP methods
- Open redirect parameters
- /.well-known endpoints
- DNS records (SPF, DMARC, CAA, DNSSEC)
- Sensitive path exposure probes
- Secret patterns in JavaScript bundles
- Published source maps
- Same-origin page crawl
These areas need signed-in access or your source code, so nothing here was checked. A clean score does not mean they are safe.
- Access rules between accounts — Whether one signed-in user can read or change another user's data. This needs test credentials for two accounts.
- Admin-only endpoints — Whether an ordinary signed-in user can reach administrator functionality.
- Database access rules — Whether row-level security or equivalent database rules are enforced correctly.
- Payment and business logic — Payment bypass, coupon abuse, expensive AI endpoint abuse, and account-recovery misuse.
- Dependency vulnerabilities — Known CVEs in your packages. A URL scan cannot see your lockfile; the code/repository scan covers this.
- JavaScript-rendered content and runtime XSS — This scan reads server responses only. It does not run a browser, so DOM-based issues are not covered.
- Authenticated pages — Only publicly reachable pages were requested, using safe GET/HEAD requests. Nothing was logged into or exploited.