home / skills / hoangnguyen0403 / agent-skills-standard / legacy-security

legacy-security skill

safe

This skill helps harden Android legacy security by enforcing intents, webview, and file exposure best practices for safer apps.

npx playbooks add skill hoangnguyen0403/agent-skills-standard --skill legacy-security

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

1.1 KB

---
name: Android Legacy Security
description: Standards for Intents, WebViews, and FileProvider
metadata:
  labels: [android, security, legacy, intents]
  triggers:
    files: ['**/*Activity.kt', '**/*WebView*.kt', 'AndroidManifest.xml']
    keywords: ['Intent', 'WebView', 'FileProvider', 'javaScriptEnabled']
---

# Android Legacy Security Standards

## **Priority: P0**

## Implementation Guidelines

### Intents

- **Implicit**: Always verify `resolveActivity` before starting.
- **Exported**: Verify `android:exported` logic (as per `security` skill).
- **Data**: Treat all incoming Intent extras as untrusted input.

### WebView

- **JS**: Default to `javaScriptEnabled = false`. Only enable for trusted domains.
- **File Access**: Disable `allowFileAccess` to prevent local file theft via XSS.

### File Exposure

- **FileProvider**: NEVER expose `file://` URIs. Use `FileProvider`.

## Anti-Patterns

- **Implicit Internal**: `**No Implicit for Internal**: Use Explicit Intents (class name).`
- **World Readable**: `**No MODE_WORLD_READABLE**: SharedPreferences/Files.`

## References

- [Hardening Examples](references/implementation.md)

Overview

This skill documents Android legacy security standards for Intents, WebView configuration, and safe file exposure. It summarizes high-priority implementation rules and common anti-patterns to prevent common vulnerabilities in legacy Android code. Use it to audit, harden, or refactor mobile apps that interact with external components, web content, or the file system.

How this skill works

The skill inspects intent usage to ensure implicit intents are validated and exported flags follow secure logic. It reviews WebView settings to enforce safe defaults for JavaScript and file access. It checks file handling to ensure file:// URIs are never exposed and FileProvider is used for sharing files securely.

When to use it

Auditing legacy Android apps for security regressions related to intents or IPC.
Refactoring modules that create or handle Intents, especially those crossing app boundaries.
Hardening WebView integrations that render external or partially trusted content.
Reviewing file-sharing code paths to prevent path traversal or unauthorized local file access.
Preparing an app for stricter platform requirements or security reviews.

Best practices

Verify resolveActivity before launching implicit intents and prefer explicit intents for internal components.
Treat all incoming Intent extras as untrusted input and validate types and content.
Default WebView.javaScriptEnabled to false; enable JavaScript only for whitelisted, trusted domains.
Disable allowFileAccess on WebView to prevent local file theft through XSS vectors.
Never expose file:// URIs; use FileProvider with properly scoped paths and permissions.
Avoid MODE_WORLD_READABLE and similar APIs that make SharedPreferences or files globally accessible.

Example use cases

Scan intent-creation code and add resolveActivity checks before starting activities.
Replace implicit-for-internal intents with explicit class-based intents to prevent confusion.
Lock down a WebView by disabling JavaScript and file access, then selectively enable JavaScript via domain checks.
Migrate legacy file share logic from file:// URIs to FileProvider with temporary content URIs.
Update manifest components to validate android:exported values according to secure design.

FAQ

Why prefer explicit intents for internal communication?

Explicit intents target a known component class, preventing other apps from intercepting or spoofing the action.

When is it acceptable to enable JavaScript in WebView?

Only when content is from trusted, validated domains and you have additional XSS mitigations; otherwise keep JavaScript disabled.