- Personal data in result records and identifiers. The client uses the submitted email as a prefix when generating
resultId, and the backend stores theuservalue in each result document. - Unauthenticated collection-wide reads. The API defines
GET /resultsandGET /surveyswithout application-level authentication or authorization. - Unauthenticated writes. The API accepts survey and result writes without an application-level identity or authorization check.
- Open CORS configuration. The Express app enables CORS without a source-defined origin allowlist.
Before any redeployment, remove email-derived identifiers, minimize or eliminate personal data, implement authentication and authorization, restrict reads and writes, review Firestore rules and IAM, establish retention/deletion behavior, and verify that historical data is not publicly reachable.
- The empty-body checks compare
JSON.stringify(req.body)with an empty string, which does not reject a normal empty object. - The backend trusts client-supplied
dimension,direction, andansarrays. - The frontend email error condition uses logical AND, so a malformed non-empty email can bypass the error flag.
- Error responses may interpolate backend error details.
- Controller logging can include full survey content.
The backend declares Node.js 8. That release line is end-of-life and is not a supported Firebase Functions runtime in 2026. The React, CRA, Axios, Material UI, Firebase, and lockfile dependency set is also historical.
This refresh intentionally avoids a blind dependency upgrade. A safe modernization would require a separate branch, test baseline, API/data migration plan, emulator validation, and explicit deployment ownership.
The audit did not establish a successful 2026 dependency installation, test run, production build, emulator run, or local end-to-end execution.
The initial audit environment could not complete an outbound Git clone. The repository owner later obtained a genuine clone and was able to inspect the original Git working tree, but no legacy runtime execution was performed.
Additional constraints included:
- the available local runtime was Node.js 22.16.0 with npm 10.9.2, rather than the backend's declared Node.js 8 runtime;
- Docker was unavailable in the initial audit environment;
- there was no safe reason to install Node.js 8 globally;
- no Firebase emulator fixture or historical data fixture was available;
- restoring legacy dependencies and producing a replacement build were deliberately excluded from the documentation-first refresh;
- the historical Firebase project was verified through its original owner account, but that does not constitute successful application reproduction.
The documented setup commands come from the historical manifests and must not be interpreted as commands successfully validated in 2026.
- The frontend contains the default Create React App “renders without crashing” test.
- No backend test script or executable test suite was found.
computeMBTI.jscontains a commented manual test block with one expected/actual mismatch (INFPversusINFJ).- No coverage report, CI workflow, performance benchmark, or production-monitoring evidence was found.
The original Firebase Hosting deployment from July 2019 remains reachable through both historical domains:
https://shiftpollmbti.web.apphttps://shiftpollmbti.firebaseapp.com
During the 2026 portfolio review, Firebase Hosting successfully served the original HTML document, stylesheets, and JavaScript bundles. However, the React interface rendered a blank page, and the application could not be validated as an operational end-to-end demo.
The exact runtime failure was not diagnosed as part of this review. No legacy dependencies were restored, no application source was modified, no new frontend build was produced, and nothing was redeployed to Firebase.
The Firebase database services reviewed in the project console appeared disabled. This supports the narrower conclusion that no active Firebase database service was observed during the review. It does not prove that historical data never existed, establish when data may have been removed, or confirm the complete historical retention lifecycle.
The current status of the historical Firebase Cloud Function must be verified separately. Until that review is complete, this repository does not claim that the backend is currently available, functional, or publicly exposed.
The hosted URLs are treated as historical deployment evidence rather than as a supported live demo.
No deployment runbook, rollback procedure, incident process, monitoring baseline, or current operational ownership documentation was found.
Static inspection identified a browser-extension-dependent pattern in the Redux store configuration. The store enhancer conditionally uses the Redux DevTools browser extension in a way that may be incompatible with environments where that extension is unavailable.
This observation was not reproduced in an isolated historical runtime and was not confirmed as the cause of the blank-page behavior observed in the hosted deployment.
No corrective source change was made because diagnosing, rebuilding, and redeploying the historical application are outside the scope of this documentation-first portfolio refresh.
- No license is present.
- No
.gitignoreappears in the 42-file implementation tree. - No
.env.exampleor environment contract is present. - No screenshots or authentic result captures are present.
- The source/provenance of the questionnaire wording is undocumented.
- Concrete historical Firebase project identifiers remain in source; they are not private credentials, but they should be reviewed and sanitized before portfolio promotion.
- Mass upgrades of Node, React, Firebase, Material UI, or lockfiles
- Deployment to Firebase
- Rewriting Git history or dates
- Creating releases or tags
- Inventing screenshots, metrics, test coverage, or production status
- Claiming the questionnaire text as original without provenance
- Diagnosing or repairing the hosted blank-page behavior through legacy runtime restoration
- Producing or deploying a replacement frontend build