Web Application & API Pentest

POST /user/authenticate returns an identical status and human message for valid vs invalid emails, but two side channels distinguish registered accounts: the JSON errors.name differs (AuthorizationError for an existing email with wrong password vs Error for a non-existent email), and an about 0.5 second timing delta (bcrypt runs only for existing accounts). Rated Low because the user-facing message is identical and impact is enabling rather than direct, but it meaningfully amplifies F15 and F16.

A known email with wrong password returned errors.name AuthorizationError at about 1.9s, while a random email returned errors.name Error at about 1.4s.

An unauthenticated attacker could reliably confirm which email addresses are registered, building a target list. The impact was enabling rather than direct, but it amplified the credential-stuffing risk from the missing login rate limiting.

Retested: FIXED — existing vs non-existent email now return an identical 401 AuthorizationError with the same message and overlapping timing (no oracle).

POST /user/authenticate enforces no rate limiting, lockout or CAPTCHA; many consecutive failures all return 401 with no 429. Combined with F14, this enables practical credential stuffing and spraying against enumerated accounts. Signup is CAPTCHA-protected but login is not.

Replaying POST /user/authenticate 12 to 30 times with wrong passwords returned 401 every time with no 429 and no lockout, and the correct password then succeeded immediately.

An unauthenticated attacker could run large-scale credential stuffing and spraying against enumerated accounts, enabling account takeover of weak or reused passwords. Chained with the enumeration oracle, the attack was efficient and targeted.

Retested: FIXED — POST /user/authenticate returns 429 after about 5 attempts (per-IP throttle).

POST /user/forgot-password applies no rate limiting; repeated requests for the same address all return 200. An attacker can flood any user inbox with reset emails (harassment or mail-bombing) and drive email cost. The endpoint does not leak account existence, since responses are uniform.

Sending POST /user/forgot-password 6 to 20 times for the same address returned 200 every time with no 429.

An unauthenticated attacker could mail-bomb any user inbox with reset emails, a harassment and cost-abuse vector. There was no data compromise, keeping the severity low.

Retested: FIXED — POST /user/forgot-password returns 429 (Too many password reset requests) after the first request.

Several endpoints leak raw MySQL syntax errors and Node stack traces with server file paths such as /app/lib/controllers/inspection_types.js. These are not exploitable SQL injection: inputs are integer-coerced (a quote becomes NaN, giving Unknown column NaN) or escaped, and even benign numeric input triggers the same error on the malformed query-builder paths. The scanner CWE-89 SQL injection titles are overstated; the real reproducible issue is verbose error and stack-trace disclosure.

GET /inspection-types/17abc returned a 400 with a MySQL error and a Node stack trace including /app/lib/ file paths.

Verbose errors revealed the DB engine, query-builder defects and server file paths to authenticated users, aiding reconnaissance. No data could be read, inferred or altered via injection, keeping the impact informational.

Retested: FIXED — GET /item/organization/v2?limit=50 (no skip) returns a generic 400 Something went wrong and the raw MySQL error is gone.

The SPA origin www.dev-fe.emory.pro (S3 and CloudFront) returns no security headers: no Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options or Referrer-Policy. The app is framable (clickjacking) and lacks transport and script hardening and HSTS (downgrade exposure). The same HSTS gap applies to the sibling host www.webapp.emory.pro. The API origin does send strong Helmet headers; this concerns the frontend origins.

GET https://www.dev-fe.emory.pro/ returned only server AmazonS3 and via cloudfront with none of the standard security headers, and /dashboard rendered inside an attacker frame.

The frontend was framable (clickjacking of a logged-in user) and lacked transport and script hardening, with an HSTS gap enabling protocol downgrade. Impact was UI-redress and downgrade exposure with no direct data compromise.

Retested: FIXED — dev-fe now serves HSTS, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy and a CSP with frame-ancestors none. Residual: the CSP is Report-Only and Server AmazonS3 is still disclosed (tracked as F35).

The production SPA ships publicly downloadable source maps: main.9553f9da.js.map (about 22 MB) exposes sourcesContent for about 1,841 original TypeScript files, including permission configuration, API routes, hidden subdomain references and S3 bucket names. The sibling host www.webapp.emory.pro exposes its own source map. This hands an attacker the full client source, accelerating discovery of endpoints and role logic such as F1.

GET https://www.dev-fe.emory.pro/static/js/main.9553f9da.js.map returned HTTP 200 (about 22 MB) with full TS source in sourcesContent, and the webapp sibling map also returned 200.

Public source maps gave an attacker the full client TypeScript source including permission configuration, API routes and S3 bucket names, sharply accelerating reconnaissance and discovery of endpoints and role logic. Alone it enabled recon rather than direct compromise.

Retested: FIXED (dev; prod pending) — dev-fe /assets/*.js.map returns 404 with no sourceMappingURL, but production www.webapp.emory.pro still served a 19 MB map at retest; re-verify after the dev build promotes to prod.

The interactive API docs at GET /docs (Scalar/OpenAPI, about 117 paths) and the raw GET /openapi.json load for any authenticated user including a read-only Customer. This discloses the full API surface, including endpoints not used by the customer UI, to the least-trusted accounts, accelerating attack-surface mapping (for example F1, F8, F9).

As a read-only Customer, https://dev-be.emory.pro/docs rendered the full OpenAPI and /openapi.json returned the full schema.

The full API surface, including endpoints not used by the customer UI, was disclosed to the least-trusted accounts, accelerating attack-surface mapping for other findings. Impact was reconnaissance value rather than direct compromise.

Retested: FIXED — EFA GET /docs and /openapi.json return 403 and unauthenticated /docs returns 401.

The frontend exposes a routable /superadmin page rendering an admin login form, and the public source maps (F19) contain superadmin-specific source files. This advertises the privileged administration surface to anyone and widens the attack surface for credential attacks against the highest-privilege console.

GET https://www.dev-fe.emory.pro/superadmin previously rendered an admin login form (HTTP 200).

The privileged superadmin login and its source were advertised on the public origin, widening the attack surface for credential attacks against the highest-privilege console. It was surface exposure rather than a direct compromise.

Retested: FIXED — GET /superadmin returns the SPA shell but the client router renders an in-app 404 Page Not Found with no admin login form, and JS source maps now 404 so the superadmin source files are no longer exposed; residual superadmin string constants route to nothing reachable.

The bulk-import endpoints do not return 403 for a read-only Customer: the customer token reaches the same import and validation pipeline as an Org Admin, with byte-identical error responses at every malformed input, whereas single-record POST /user/signup and POST /item correctly return 403. This strongly suggests the bulk endpoints lack the function-level gate applied elsewhere; because the user import accepts a User Role column, a successful low-priv bulk import could also be a privilege-escalation path. Actual record creation was not reproduced because the proprietary spreadsheet schema rejected test files.

A read-only Customer POST /bulk-upload/user produced responses byte-identical to an Org Admin at every stage and never 403, while POST /user/signup returned 403.

If confirmed, a low-privilege account could bulk-create records including Org Admin users, a privilege-escalation path via the User Role import column. The barrier observed was the spreadsheet schema, not an authorization control, so the risk depended on where the authz check sits relative to file parsing.

Retested: FIXED — EFA POST /bulk-upload/user returns 403 (previously reached the admin pipeline).

The marketing host emory.pro (and www.emory.pro) runs WordPress with a publicly reachable admin login (/wp-login.php returns 200) and an open REST API index (/wp-json/ returns 200) that enumerates routes and plugin inventory. While distinct from the inspection app, this expands the organization attack surface (WordPress brute-force, plugin-CVE exposure, user enumeration) and was surfaced during scope discovery.

GET https://emory.pro/wp-login.php returned 200 (WordPress login) and GET https://emory.pro/wp-json/ returned a 200 route and plugin index.

The public WordPress admin and REST API expanded the organization attack surface with brute-force, plugin-CVE and user-enumeration exposure. It was distinct from the inspection app and low impact but widened reconnaissance opportunities.

Retested: FIXED — the site migrated to Framer; /wp-login.php returns 404 and /wp-json/wp/v2/users returns non-WP HTML with no REST or user enumeration.

Unlisted sibling hosts respond publicly, broadening attack surface beyond the documented scope: werkerapp-heinrichs.emory.pro (a logistics management interface) returns 200, and www.webapp.emory.pro serves a production frontend with its own exposed source maps (see F19). These should be inventoried, access-controlled or decommissioned.

GET https://werkerapp-heinrichs.emory.pro/ and GET https://www.webapp.emory.pro/ both returned HTTP 200.

Additional public management UIs and a production frontend with exposed source maps broadened the organization attack surface beyond the documented scope. The exposure required host discovery, bounding likelihood.

Retested: FIXED (dev; prod pending) — werkerapp was client-descoped as a separate demo project, but www.webapp.emory.pro (prod) was still reachable and serving source maps at retest; resolved once the dev changes ship to prod, re-verify then.

The production web origin /.well-known/assetlinks.json delegates Android App Links (delegate_permission/common.handle_all_urls) to mobile packages such as pro.emory.inspections with specific signing fingerprints. If any delegated package corresponds to a development or staging or otherwise less-controlled build, that app can claim and intercept the production domain deep links.

GET https://dev-fe.emory.pro/.well-known/assetlinks.json returned HTTP/2 200 still delegating to pro.emory.inspections.dev with fingerprint AD:A9:9B:CB:D2:3E:99:2B:...:CC:2F.

A dev or staging (less-controlled) Android package delegated in production assetlinks could claim and intercept the production domain deep links, enabling deep-link interception and phishing on mobile. Exploitation required control of or trust in a delegated package.

Retested: FIXED (code fix verified; client-confirmed, pending production deployment). The client added a build-time generator (genWellKnown.mjs) that produces per-environment App Links / Universal Links association files, so each web origin delegates deep links only to its own signed build — prod (webapp.emory.pro) delegates only to pro.emory.inspections, dev (dev-fe.emory.pro) only to pro.emory.inspections.dev, with unknown/unset env failing safe to prod. This prevents the production origin from vouching for a dev/staging signing key. Client note: we have this file in place; it ensures cross-environment leaking does not take place; as these changes are not in prod yet you would not be able to check that; dev-fe.emory.pro points to the dev app and webapp.emory.pro to the prod app. CredShields verified dev-fe.emory.pro now delegates only to the dev package; re-verify the production file once the change is promoted to webapp.emory.pro.

The production JavaScript bundle fingerprints elliptic 6.5.2, a version with known cryptographic-signature-handling advisories (later patched in the 6.5.x line). Risk depends on whether the affected ECDSA code paths are exercised client-side, but the outdated component should be upgraded.

elliptic version 6.5.2 was fingerprinted in the production bundle and source map.

A known-vulnerable crypto dependency was shipped to the client, introducing a cryptographic signature-handling weakness if the affected ECDSA code paths were exercised. Impact was contingent on the reachable code paths.

Retested: FIXED — elliptic is absent from all dev-fe Vite chunks.

The frontend loads third-party-hosted stylesheets without a Subresource Integrity (integrity) attribute, so a compromise of or MITM against the third-party origin could inject attacker-controlled CSS or content into the application.

External stylesheet link tags in the frontend HTML lacked integrity and crossorigin attributes.

A compromise of or MITM against the third-party stylesheet origin could inject attacker-controlled CSS or content into the application, a style and content-injection vector. Exploitation required third-party or MITM compromise, keeping likelihood low.

Retested: FIXED — frontend CSS is now self-hosted and same-origin with no external stylesheet links.

POST /tasks/templates accepts negative field sequence values (for example -5, persisted verbatim) and duplicate item_type_ids in a single template (for example [586,586], both stored). These are data-quality and integrity gaps with no direct security impact (worst case UI ordering glitches), but they reflect missing server-side validation and are worth tightening.

POST /tasks/templates with duplicate item_type_ids [586,586] and sequence -5 returned 201 with both stored verbatim.

Missing input validation allowed malformed templates (negative sequence, duplicate item-type references) to persist, a data-integrity gap with no direct security impact beyond possible UI ordering glitches.

Retested: FIXED — item_type_ids [586,586] plus sequence -5 now returns 400 (duplicate value and sequence must be at least 0).

POST /tasks/templates stores a template name containing raw HTML (for example an svg onload payload) and returns it unescaped in the JSON API response. In the JSON context this is inert; it becomes stored XSS only if the frontend renders the template name through an unescaped DOM sink. The value is persisted unsanitized, which is the precondition for stored XSS, flagged Low pending confirmation of a rendering sink in the UI.

POST /tasks/templates stored an svg onload template name and GET returned the raw HTML unescaped in the JSON response.

Unsanitized HTML persisted in the template name, the precondition for stored XSS if the frontend ever rendered it through an unescaped DOM sink. In the JSON API response it was inert, so the risk was latent pending a confirmed UI sink.

Retested: FIXED — a template name with an svg onload payload is now stored as plain text with HTML stripped server-side.

The password set and reset flow enforces only a minimum length of eight characters, with no complexity, dictionary or breached-password checks. Users can therefore set weak or previously-breached passwords (for example password), which materially increases the success rate of the credential-stuffing and brute-force attacks made practical by the absence of login rate-limiting (F15) and the username-enumeration oracle (F14).

A password reset accepted a new password of password (8 characters, no complexity) with no policy error.

Weak and previously-breached passwords were accepted, raising the likelihood of successful credential-stuffing and brute-force attacks, especially chained with the missing login rate limiting and the enumeration oracle. It weakened account-takeover resistance across the platform.

Retested: FIXED — the policy now requires at least 12 characters with uppercase, lowercase, number and special character; every weak password was rejected with a specific 400 and a compliant password was accepted (200).

Organization signup is protected by Google reCAPTCHA v3, a score-based fully invisible mechanism that a normal browser auto-mints with no human interaction. Server-side verification of the token is present, but because a real (or headless-but-real) browser obtains a passing score without solving any challenge, the practical barrier against automated or bulk signups is weak. This enables automated account and organization creation (spam, resource abuse, cost amplification).

An automated real browser minted an invisible reCAPTCHA v3 token that was accepted with no human challenge, allowing repeated automated signups.

Bulk and automated organization creation was feasible, enabling spam and resource and cost amplification. Because a scripted real browser passed reCAPTCHA v3 without interaction, the practical anti-automation barrier was weak.

Retested: LARGELY FIXED — per-IP Cloudflare rate limiting now returns 429 (a 30-request burst returned 27 of 429, only 3 reached the backend) and reCAPTCHA verification is enforced (a forged token fails, no account created). Residual: the mechanism is still invisible reCAPTCHA v3 with no interactive step-up, and a bogus token yields a generic 500 rather than a clean 400.