Aigent.ly — Vulnerability Prevention for AI-Generated Code

Rule body

AI Summary

AI Security Summary

Android Bluetooth APIs expose sensitive device capabilities that require strict permission enforcement at every call site. The recurring mistake is omitting or insufficiently checking runtime permissions before executing privileged Bluetooth operations.

Bluetooth Permission Bypass via Missing Runtime Checks

Covers: CVE-2024-0045 Risk: Attackers can invoke privileged Bluetooth operations without holding required permissions, enabling unauthorized device discovery or pairing.

ALWAYS verify that the caller holds the required Bluetooth runtime permissions before executing any Bluetooth stack operation.
NEVER assume that a permission granted at install time is still valid at runtime — re-check permissions at each sensitive call site.
ALWAYS enforce permission checks on both the initiating entry point and any internal helper methods that access Bluetooth resources.
NEVER expose Bluetooth control paths through exported components (Activities, Services, BroadcastReceivers) without gating them behind explicit permission validation.
ALWAYS use checkSelfPermission or equivalent platform APIs to assert permission state, and fail closed by default if the check does not explicitly return PERMISSION_GRANTED.

Cross-cutting patterns (all Android / Kotlin projects)

ALWAYS apply the principle of least privilege: request only the specific permissions your code path requires and no broader set.
NEVER trust caller-supplied context or identity tokens as a substitute for a platform-level permission check.
ALWAYS design exported Android components to reject or silently no-op requests that arrive without the expected permission, rather than failing open.

View all CVE patterns

# Android / Kotlin security patterns

Safe, always-on code patterns that reduce security risk without changing your dependency graph.

These rules use ONLY pattern-level verbs (ALWAYS/NEVER). They MUST NOT prescribe dependency upgrades.

### CVE-2024-0045 — safe patterns

- ALWAYS verify Bluetooth permissions (BLUETOOTH, BLUETOOTH_ADMIN, BLUETOOTH_SCAN) before device operations.
- NEVER assume implicit permission inheritance from manifest declarations to runtime operations.
- ALWAYS check runtime permissions at point-of-use, not just at app initialization.

# Android / Kotlin security patterns Safe, always-on code patterns that reduce security risk without changing your dependency graph. These rules use ONLY pattern-level verbs (ALWAYS/NEVER). They MUST NOT prescribe dependency upgrades. ### CVE-2024-0045 — safe patterns - ALWAYS verify Bluetooth permissions (BLUETOOTH, BLUETOOTH_ADMIN, BLUETOOTH_SCAN) before device operations. - NEVER assume implicit permission inheritance from manifest declarations to runtime operations. - ALWAYS check runtime permissions at point-of-use, not just at app initialization.

AI Security Summary

Bluetooth Permission Bypass via Missing Runtime Checks

Covers: CVE-2024-0045 Risk: Attackers can invoke privileged Bluetooth operations without holding required permissions, enabling unauthorized device discovery or pairing.

ALWAYS verify that the caller holds the required Bluetooth runtime permissions before executing any Bluetooth stack operation.

NEVER assume that a permission granted at install time is still valid at runtime — re-check permissions at each sensitive call site.

ALWAYS enforce permission checks on both the initiating entry point and any internal helper methods that access Bluetooth resources.

NEVER expose Bluetooth control paths through exported components (Activities, Services, BroadcastReceivers) without gating them behind explicit permission validation.

ALWAYS use checkSelfPermission or equivalent platform APIs to assert permission state, and fail closed by default if the check does not explicitly return PERMISSION_GRANTED.

Cross-cutting patterns (all Android / Kotlin projects)

ALWAYS apply the principle of least privilege: request only the specific permissions your code path requires and no broader set.

NEVER trust caller-supplied context or identity tokens as a substitute for a platform-level permission check.

ALWAYS design exported Android components to reject or silently no-op requests that arrive without the expected permission, rather than failing open.

Protects against

Rule body

AI Security Summary

Bluetooth Permission Bypass via Missing Runtime Checks

AI Security Summary

Bluetooth Permission Bypass via Missing Runtime Checks