hy/aslan-h5
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
aslan-h5/docs/安全/前端加固.md

11 KiB
Raw Permalink Blame History

Frontend Hardening Notes

Purpose

This document records the frontend-only hardening currently applied on the main branch to raise the cost of scraping, asset reuse, and low-effort page reconstruction.

The goal is to make abuse less convenient, not to claim absolute protection.

Scope

All changes described here stay within the frontend project.

They do not rely on:

  • backend API changes
  • private OSS buckets
  • signed image URLs
  • server-side image rewriting

What Was Added

1. Protected page access control

Protected routes are blocked outside the official app environment in production-like modes.

Main files:

Behavior:

  • public routes still open normally
  • protected routes redirect to /#/not_app outside the app
  • protected API requests are rejected when the app bridge is unavailable

2. Runtime anti-debug and anti-copy restrictions

Protected pages add a lightweight runtime restriction layer in production-like modes.

Main files:

Behavior:

  • blocks common devtools shortcuts
  • blocks right-click, drag, copy, and text selection on protected pages
  • reduces long-press image save convenience

3. Protected asset URL layer for Activities and Ranking

Most Activities/ and Ranking/ image references no longer expose raw OSS URLs directly in templates.

Main files:

Behavior:

  • getPngUrl() and getWebpUrl() emit likei-protected:...
  • runtime code resolves protected URLs only when rendering is needed
  • most image rendering flows now end up using cached blob/object URLs
  • pages that missed v-smart-img still get a runtime fallback for protected image src

4. background-image compatibility fixes

Several high-risk pages previously exposed asset URLs through inline background-image: url(...).

Adjusted files:

Behavior:

  • protected helpers are used before writing image values into CSS
  • fewer raw asset URLs appear directly in template or style strings

5. Build artifact readability reduction

Build output names were changed from readable page/component names to hash-based filenames.

Main file:

Behavior:

  • JS chunk names no longer reveal page names such as TopList, WeeklyStar, or Ranking
  • CSS files also use hash-based names
  • static asset filenames are hash-based

6. Production log stripping with a troubleshooting switch

Production-like builds strip common debug output while still supporting a keep-logs build for app-side troubleshooting.

Main files:

Behavior:

  • production builds remove console.log
  • production builds remove console.debug
  • production builds remove console.info
  • production-like builds remove debugger
  • console.warn and console.error are preserved
  • Jenkins can keep using the original default build commands

Useful commands:

npm run build:prod
npm run build:prod:logs

7. Deferred main DOM mounting for selected high-risk pages

Some activity and ranking pages previously used v-show="!isLoading" for the main content. That kept the full DOM tree mounted early, which made initial inspection easier and also caused some observer timing issues.

These pages were updated to mount their main content with v-if="!isLoading" instead:

Extra handling was added where needed:

  • pages with IntersectionObserver targets now register observers only after await nextTick()
  • preload completion still clears isLoading in finally, so preload failures do not leave the page permanently blank

8. Decorative background stacks

The shared background layer component previously supported a canvas rendering mode for stacked background images. This mode has now been disabled because large canvas backgrounds can increase memory and rendering pressure on low-end WebViews.

Main file:

Pages may still pass useCanvas, but the prop is now kept only for compatibility:

Behavior:

  • stacked decorative backgrounds are rendered as normal <img> elements through v-smart-img
  • image loading still goes through protected asset resolution and the existing runtime/cache pipeline
  • canvas background rendering is no longer used as a hardening layer because the UX and memory cost is higher than the practical protection gain

9. Stronger production minification and selector cleanup

Production-like builds use stricter esbuild minification flags, and a small set of highly readable page-local class names was reduced on sensitive pages.

Main files:

10. Ranking/Couple comment cleanup and helper clarification

Recent cleanup also covered:

Behavior:

  • garbled comments in Ranking/Couple/Ranking.vue were cleaned up and unified into Chinese comments
  • useCanvas remains accepted for compatibility, but BackgroundLayer ignores it and renders image backgrounds
  • toCssBackgroundImage() stays as the CSS bridge for protected asset URLs

What This Helps Against

This frontend-only hardening is helpful against:

  • direct browser opening of protected routes
  • low-effort DOM scraping
  • copying image URLs from templates or page source
  • reading obvious page intent from build artifact names
  • simple right-click, drag-save, long-press, and casual copying
  • basic page reconstruction that depends on immediately available DOM structure

Current Limits

These changes still do not fully prevent:

  • network-level image capture
  • devtools users with enough time and persistence
  • custom WebView, automation, or hook-based extraction
  • rebuilding the same layout after visual inspection
  • extracting DOM, CSS, and JS from any client that is allowed to render the page

If the client can render the page, the client must receive enough information to reproduce it. Frontend-only hardening can only increase cost, not provide absolute protection.

Recommended Testing

Protected route blocking

Use:

npm run dev:prod

or:

npm run build
npm run preview

Asset and page rendering checks

In production-like mode, verify:

  • Activities and Ranking pages still render correctly
  • protected page images still display normally
  • protected asset URLs are less visible in runtime DOM and build output
  • pages switched from v-show to v-if still render after preload completes
  • pages with load-more observers still trigger lazy loading correctly

Build output checks

Run:

npm run build

Expected:

  • dist/js filenames are hash-based
  • dist/css filenames are hash-based
  • no obvious page names appear in bundle filenames
  • production bundles no longer retain console.log, console.debug, console.info, or debugger