Sensitive facilities and tiles exposed in a public front-end bundle

• Scan finding on `/assets/index-3e8a21.js`: it contains facility names and coordinate literals such as 116.39, 39.90 in plain text
• `curl -I https://oss.example.cn/gis/secret/12/3412/1420.pbf` returns `HTTP/1.1 200 OK` with `x-oss-object-acl: public-read`
• `grep -r "secret\|classified\|pipeline" dist/assets/` matches the built bundle

1. Grep the build output for sensitive field names and exact coordinate literals
2. Check `src` for `.geojson`, `.shp` or `.gpkg` files that are imported directly
3. Request a tile and a data endpoint with an unauthenticated `curl` and look for 200
4. Review the bucket policy and the CDN origin configuration
5. Check whether test or demo environments use production data

Keep sensitive data out of the bundle and fetch it at runtime from an authenticated endpoint (`fetch('/api/secure/features', { headers: { Authorization: 'Bearer ' + token }, credentials: 'include' })`), serve tiles from a private bucket behind signature URLs or an `auth_request` proxy, and generalize coordinates before public display.

[高危] 前端静态资源包含敏感地理信息
  文件: /assets/index-3e8a21.js
  命中: "变电站","管线走向",116.39,39.90

[高危] 对象存储桶允许匿名读取
  GET https://oss.example.cn/gis/secret/12/3412/1420.pbf
  HTTP/1.1 200 OK
  x-oss-object-acl: public-read

grep -r "secret\|classified\|管线" dist/assets/ | head
curl -I "https://oss.example.cn/gis/secret/12/3412/1420.pbf"
# 期望 403；返回 200 即为公开可读

• Relying on minification or renamed variables; the coordinates and names remain plain strings in the bundle
• Setting the bucket to `public-read` and assuming an unguessable path protects it, when z/x/y paths are trivially enumerable