How to Protect Customer Data in Web and Mobile Apps

Customer data can be exposed through an overlooked API, a lost phone, a misconfigured cloud service or an account takeover. Protecting it is therefore not a single feature: it is a set of decisions about what an application collects, who can access it and how the organization responds when something goes wrong.

For organizations commissioning or improving a digital product, the practical goal is to make those decisions visible and testable before launch—and maintain them afterward.

Start with a map of the data

List the customer information the application collects, why it is needed, where it travels and how long it is retained. Include databases, analytics tools, support platforms, logs, backups and third-party services. Assign an owner to each important data flow.

Then remove fields and integrations that do not serve a clear purpose. Define retention periods and a deletion process that accounts for copies and backups. Use synthetic or appropriately de-identified data for development and testing where possible. Data minimization is also a principle of the GDPR where that regulation applies; the European Commission’s overview of GDPR principles explains the distinction between limiting collection and limiting storage.

Control access on the server, not just the screen

Authentication establishes who is signing in; authorization determines what that account may do. Both matter. Require multifactor authentication for administrative accounts and consider phishing-resistant options such as passkeys for appropriate users and risk levels. Plan secure account recovery too: a strong sign-in method is less useful if recovery can be easily abused. The NIST Digital Identity Guidelines provide a framework for choosing authentication controls.

Enforce permissions in trusted server-side code for every sensitive request, including API calls, downloads and changes. Deny access by default, limit administrative privileges and check ownership or organization membership at the record level. Hiding a button in the app is not an authorization control. For example, changing an invoice identifier in a request must not let one customer retrieve another customer’s invoice. OWASP’s guidance on broken access control describes these failure modes and recommends server-side enforcement.

Protect data in transit, at rest and on devices

Use HTTPS with proper certificate validation for application and API traffic. Encrypt sensitive stored data and backups according to the risk, and manage encryption keys separately from the data they protect. Limit access to keys and plan for rotation and recovery. Encryption reduces exposure, but it does not replace authorization: an application with legitimate decryption access can still disclose data to the wrong user.

For mobile apps, keep sensitive information off the device unless the product needs it. When local storage is necessary, use platform security mechanisms such as iOS Keychain and Android Keystore for appropriate secrets and keys. Review caches, notifications, backups and logs for unintended exposure, and clear sensitive local data when it is no longer needed. The OWASP Mobile Application Security Verification Standard is useful for mobile-client checks; its guidance also recommends assessing the backend separately.

Build security checks into delivery

Use a threat model to identify likely abuse paths, such as account takeover, cross-customer access and exposed administrative interfaces. Before each release, combine code review and automated checks with targeted manual testing. Include dependency and configuration reviews, input handling, session management and authorization tests. The OWASP Top 10:2025 is a useful awareness starting point, while the OWASP Application Security Verification Standard provides more detailed requirements that can be selected for a project and used in acceptance criteria.

Test with at least two accounts and relevant roles: attempt to read, change and download another account’s records through both the interface and direct API requests. Record findings, assign owners and retest fixes. A clean scan alone is not evidence that every business permission works correctly.

Prepare for incidents and recovery

Log security-relevant events such as failed sign-ins, access denials and privileged changes without recording passwords, access tokens or unnecessary customer data. Protect the logs, set alerts that someone will actually review, and agree on escalation contacts. Maintain protected backups and regularly test restoration, including the time and access needed to recover.

Write an incident plan covering containment, evidence preservation, customer communication and notification decisions. Requirements vary by jurisdiction. For example, where the GDPR applies, a controller generally must notify the relevant authority within 72 hours of becoming aware of a personal data breach unless the breach is unlikely to risk individuals’ rights and freedoms; delays must be explained. See the European Data Protection Board’s breach notification summary. Obtain qualified legal advice for the circumstances and markets involved.

Set expectations with delivery partners

Whether work is handled in-house, outsourced or delivered by an augmented team, agree on responsibilities before development starts. Specify who owns the infrastructure, customer data, keys, security fixes, monitoring and incident response. Ask suppliers which subcontractors and data-processing services are involved, what access they need, how vulnerabilities are reported and how data and access are returned or removed at the end of the engagement.

Make evidence part of acceptance: request a data-flow diagram, a prioritized findings register, test results with scope and dates, and a maintenance plan. The CISA Secure by Demand Guide offers questions buyers can use when evaluating software suppliers. Altweeb’s software development, technology consulting and team augmentation services are relevant engagement options; the scope and security responsibilities should be agreed for each project.

Where to begin

If resources are limited, first inventory sensitive data, close cross-customer access gaps, secure administrator accounts and verify that backups can be restored. Follow with repeatable testing and a named owner for ongoing remediation. No control guarantees perfect security, but a documented, tested process makes customer data protection more manageable.

To explore this further, see Digital products built around specific needs..