T09 · Insecure Skill Coding Practices
- Location
references/qiankun.md:14- Finding
Raw authentication token delegated to independently loaded qiankun sub-applications
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a micro-frontend guide, but it includes insecure authentication-token and remote-code-loading examples without enough safety guidance.
Review this skill before relying on it for production architecture. If installed, explicitly tell the agent to avoid bearer tokens in localStorage/sessionStorage, avoid passing raw tokens to sub-apps, pin and lock code-generation tools, and require trusted origins, immutable versions, manifest protection, CSP, and integrity checks for remotely loaded micro-frontends.
references/qiankun.md:14Raw authentication token delegated to independently loaded qiankun sub-applications
references/communication.md:79Authentication token stored in script-readable localStorage
references/single-spa.md:34Runtime remote JavaScript execution without documented integrity controls
references/module-federation.md:97Unpinned package retrieval and immediate execution through npx
The documentation presents subscribe as returning a cleanup function, but the code adds an anonymous wrapper listener and later tries to remove the original handler reference. Because removeEventListener must receive the same function object that was registered, the shown cleanup does not actually unsubscribe, contradicting the comment // cleanup.
The guide recommends storing an auth token in localStorage and sharing it across sub-apps without warning that web storage is readable by any script running in the origin. In a micro-frontend architecture, the shared-origin model and increased script surface make XSS or compromised sub-app code especially dangerous, because theft of a persisted token can lead to account takeover and session abuse.
Data is uploaded to cloud storage (S3 / GCS / Azure Blob). This may be a legitimate backup or exfiltration to an external bucket. Manual review is recommended.
- uses: actions/checkout@v4
- run: cd apps/app-orders && npm ci && npm run build
- name: Upload to CDN
run: aws s3 sync dist/ s3://my-mfe-cdn/app-orders/${{ github.sha }}/
- name: Update manifest
run: |
curl -X PATCH https://api.example.com/manifest \
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
run: aws s3 sync dist/ s3://my-mfe-cdn/app-orders/${{ github.sha }}/
- name: Update manifest
run: |
curl -X PATCH https://api.example.com/manifest
-d '{"app-orders": "${{ github.sha }}"}'
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
run: aws s3 sync dist/ s3://my-mfe-cdn/app-orders/${{ github.sha }}/
- name: Update manifest
run: |
curl -X PATCH https://api.example.com/manifest
-d '{"app-orders": "${{ github.sha }}"}'
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
run: aws s3 sync dist/ s3://my-mfe-cdn/app-orders/${{ github.sha }}/
- name: Update manifest
run: |
curl -X PATCH https://api.example.com/manifest
-d '{"app-orders": "${{ github.sha }}"}'
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
run: aws s3 sync dist/ s3://my-mfe-cdn/app-orders/${{ github.sha }}/
- name: Update manifest
run: |
curl -X PATCH https://api.example.com/manifest
-d '{"app-orders": "${{ github.sha }}"}'
The documentation recommends running an unpinned package directly with npx, which fetches and executes the latest published version at runtime. If the package is compromised, typo-squatted, or a breaking/malicious release is published, users following the guide could execute attacker-controlled code on their machine or in CI.
The root config passes an authentication token from localStorage into a sub-application via customProps, expanding the token's exposure surface to independently loaded micro-frontends. In a single-spa architecture, sub-apps may be deployed separately and loaded at runtime from CDN origins, so sharing bearer tokens this way increases the risk of token theft or misuse if any sub-app or its supply chain is compromised.