App Security Guide
This document provides security guidelines that must be followed when developing Pleos Connect apps. These guidelines go beyond simple recommendations and define essential standards for protecting users' personal information and sensitive vehicle data. All apps must be developed to maintain a high level of security so users can use services with confidence. Failure to comply with these guidelines may result in failing app review.
Sensitive Data Management
When developing an app, sensitive information such as Personally Identifiable Information (PII), financial information, sensitive vehicle data, authentication tokens, and security-critical secrets (for example API keys and encryption keys) must be protected from exposure. Minimize unnecessary storage of sensitive information, and when storage is functionally required, follow the principles below.
- Data Encryption: Sensitive information stored on a device must be encrypted regardless of storage location. The same principle applies to internal/external app storage, cache, SQLite databases, and SharedPreferences. In addition to internal sandbox protection, apply app-level encryption, and ensure temporary files or copies created during encryption do not retain sensitive information in plain text. For implementation details, refer to Secure Encryption Usage below.
- Log Data Management: Ensure sensitive information is not recorded in debug logs during development and testing. Before release, disable related log output or mask sensitive information.
- Cache Data Management: Avoid storing sensitive information in cache whenever possible. If caching is functionally required, protect it through encryption, and delete caches and temporary files after their purpose is complete.
- Disable Automatic Backup: In Pleos Connect non-GAS AAOS environments, Google-based app data auto backup is currently not used. Considering the same app may be deployed to other Android environments, disabling unused auto backup is recommended. In environments where backup is used, exclude files or directories containing sensitive data from backup targets.
- External Storage Caution: Store sensitive information in app-specific internal storage whenever possible. If external storage must be used, encrypt data according to Secure Encryption Usage. For app-only files, prefer app-specific storage over public areas, and delete app-managed temporary files after use.
- Prevent Sensitive Information Exposure in URLs: Ensure sensitive information such as authentication tokens, session information, and passwords is not included in URL paths or query parameters. URLs may be logged by servers or proxies, so pass authentication tokens through safer methods that do not expose them in URLs (for example the
Authorizationheader).
Secure Encryption Usage
To protect user data safely, it is important to consider both the safety of cryptographic algorithms and proper implementation practices. Use the following guidance when implementing encryption.
- Use Secure Cryptographic Algorithms: Use standardized algorithms with verified security. For digital signatures or security-focused integrity verification, use appropriate algorithms such as SHA-256 instead of hash algorithms with known collision weaknesses (for example MD5 and SHA-1).
- Use Secure Block Cipher Modes: Use verified cipher modes such as AES-GCM that protect both confidentiality and integrity. Avoid ECB mode because it can reveal patterns in identical plaintext blocks.
- Use Secure Padding Methods: For encryption schemes requiring padding, use standard padding suitable for the algorithm and use case. For example, OAEP with SHA-256 can be considered for RSA encryption. AES-GCM is a mode that does not require separate block padding.
- Use Initialization Vectors Safely: Use IVs that satisfy required length and generation conditions for the selected algorithm and mode. In particular, for AES-GCM, avoid reusing the same IV/nonce with the same key.
- Use Secure Random Number Generators: When generating encryption keys or random values such as IVs, use cryptographically secure random number generators. Avoid generating cryptography-related values using predictable general-purpose random generators.
- Manage Encryption Keys Securely: Protect encryption keys using secure key storage and management features such as Android Keystore. Do not hardcode keys in source code, resources, or configuration files, and do not store keys in plain text together with protected data.
Building a Secure Communication Environment
When apps communicate with external networks, sensitive information may be exposed or tampered with. To protect users and provide a trustworthy service, follow the principles below.
- Use Secure Protocols: External communication must use encrypted secure protocols such as HTTPS. Even when another communication method is functionally required, protect transmitted data so sensitive information is not exposed in plain text.
- Use Secure TLS Versions: For TLS communication, use TLS 1.2 or later at minimum, and TLS 1.3 is recommended. Configure allowed protocol versions to safe ranges and prevent fallback to insecure legacy versions such as SSL and TLS 1.0/1.1.
- Use Secure Cipher Suites: Use cipher suites with verified security. Especially for TLS 1.2, review and manage cipher suite configuration carefully.
- Communicate with Trusted Servers: Servers connected by the app must be trusted and required for service operation. Prevent communication with malicious servers or servers unrelated to normal app functionality.
- Safely Handle Server Remote Commands: If the app executes commands received from a server, verify command origin, validity, and integrity. Restrict executable commands and action scope to only what is necessary for service operation.
Component and Permission Management
Safely managing interaction between the app and the operating system is a key part of protecting user data and devices. Limit unnecessary permission requests, minimize external exposure of internal components, and appropriately control access to data and features.
- Limit Unnecessary Permission Use: Request only permissions required for app functionality and restrict usage scope according to least-privilege principles. Even when deploying the same app across multiple environments, manage permissions based on actual needs and usage purpose in Pleos Connect.
- Limit Unnecessary Component Exposure: Components such as Activity, Service, BroadcastReceiver, and ContentProvider that do not need to be called by external apps must not be externally exposed.
- Secure Data Transfer: When passing sensitive information to other apps or components, explicitly define recipients. Prevent sensitive information from being sent through unrestricted mechanisms such as implicit broadcasts.
- Control Access to Data and Features: Apply appropriate access controls to components that provide sensitive information or execute protected features. Even when external exposure is required, verify both caller authentication status and permissions for the target data/feature, and allow access only when both conditions are satisfied.
- Restrict Local Resource Access: Restrict WebView local file access to only what app functionality requires. Disable related access features when local files are unnecessary. Even when local file usage is required, protect against external content accessing sensitive internal files or data.
- Validate and Normalize URIs: Validate and normalize externally provided URIs or file paths before use. Ensure URI type, target, and path are within allowed ranges to prevent unintended access to files or data.
Secure Development and Deployment
App code directly handles user data, so security must be prioritized from the development stage. To provide safe and trustworthy apps, follow these principles.
- Use Approved APIs: Use only APIs officially provided and approved by Pleos. To maintain vehicle system stability and security, ensure unauthorized APIs are not included in the app.
- Use Only Necessary APIs: Vehicle-related APIs should be used only within the scope directly related to app functionality. Reduce unnecessary data access and feature invocation.
- Prevent Hardcoding of Sensitive Information: Ensure secrets such as authentication tokens and secret keys are not hardcoded in source code, resources, or configuration files. Device-managed encryption keys must be protected according to the key-management principles in Secure Encryption Usage.
- Manage Server Addresses Safely: Rather than hardcoding server IP addresses in source code or resources, use manageable connection targets such as domain names. Manage updates so server address changes can be applied safely.
- Protect Native Libraries: If native libraries are used, apply memory protection features to reduce exploitability of vulnerabilities. Recommended protections include RELRO, Stack Canary, and NX bit protection.
- Use SDKs and Libraries Securely: Periodically review known security vulnerabilities in SDKs and libraries used by the app, and maintain versions with security patches. Prioritize review and mitigation of vulnerabilities with high security impact.
- Use Release Certificates: Distribution builds must use official release signing certificates, not test or debug certificates.
- Disable Debugging: For final release apps, disable app debugging, debug build settings, and WebView remote debugging. Ensure no development/test settings remain in production builds.
Secure Browser and WebView Usage
Browsers and WebView can be exposed to security risks such as malicious sites, script execution, and sensitive information leakage while processing web content. Apply security controls according to app functionality and web content characteristics.
Apps Using WebView
The principles described earlier also apply to apps using WebView, including secure communication, sensitive data management, debugging disablement, local resource access restriction, and data/feature access control.
It is recommended to limit WebView-loadable content and navigable site scope to what app functionality requires. Use JavaScript execution or web-to-app integration features only when necessary, and ensure untrusted content cannot access sensitive information or protected app functionality.
Additional Requirements for Web Browser Apps
The following items apply to web browser apps.
- Use Trusted Browsers: Only browsers that use trusted engines with supported security updates can be registered in Pleos App Market. If critical security vulnerabilities are disclosed in the browser engine in use, apply a version where the vulnerability is fixed.
- Restrict Access to Malicious Sites: It is recommended to provide protections that restrict access to dangerous sites, including malicious and phishing sites.
- Prefer HTTPS and Provide Risk Notices: If a site requested over HTTP supports HTTPS, it should be connected through HTTPS. If connecting to a site that does not support HTTPS, provide warnings or guidance about the risk of unencrypted connections.
- Validate Server Certificates: For HTTPS communication, properly validate certificate trust chain, validity period, and hostname. Do not bypass validation by blindly trusting all certificates or ignoring certificate errors.
- Protect Cross-Origin Access: Correctly enforce SOP (Same-Origin Policy) and CORS (Cross-Origin Resource Sharing) so unauthorized origins cannot read responses from other origins. Do not arbitrarily relax browser cross-origin restrictions or bypass server-defined CORS policies.
- Support Content Security Policy: Web browsers must support CSP (Content Security Policy) Level 2 or higher and correctly apply site-defined CSP rules. For web content directly provided by the app, applying CSP that limits script and external resource sources to required scopes is recommended.
- Safely Process HTML and JavaScript: Ensure browser validation, filtering, and security features are properly applied to prevent code execution or data leakage caused by malicious content during HTML and JavaScript processing.
- Preserve Browser Sandbox Protections: Ensure built-in protections such as process isolation and sandboxing work correctly. Prevent web content from accessing app-internal data or system resources beyond allowed scope.
- Restrict Development/Configuration Features: In final release builds, disable developer mode, arbitrary proxy configuration changes, and extension installation.
- Restrict File Downloads: File download features through the web browser should be restricted. Manage behavior so web content cannot store unnecessary files or executable content in the vehicle environment.