> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/nfc-wallet-sdk-ios/security-and-privacy/security-guidance.md).

# Security guidance

## Overview

Use this security guidance when building and releasing an iOS **digital wallet application** that integrates the NFC Wallet SDK.

This guidance is a set of security guidelines you must apply before release.

## General security guidelines

### Use the latest NFC Wallet SDK release

Use the latest NFC Wallet SDK release. It includes the latest security updates and fixes.

### Use the Release build of the NFC Wallet SDK

Before publishing to the App Store, configure your digital wallet application to use the `Release` build.

{% hint style="warning" %}
The `Debug` SDK variant is not allowed in Production Environment.
{% endhint %}

### Strip debug symbols

Do not release with debug symbols. This practice increases the complexity of reverse engineering efforts and prevents the easy identification of sensitive variables, structures, and logic.

### Prevent sensitive data leaks

Clear sensitive data from the UI before the application enters the background.

Encrypt or wipe data until the application returns to the foreground.

Avoid logging sensitive information.

### Use code obfuscation

Use obfuscation to increase the cost of reverse engineering.

### Secure network communication

Use HTTPS for all network calls to the digital wallet backend.

Avoid self-signed certificates.

If you implement certificate pinning, follow these guidelines:

* Match the hostname against the leaf certificate.
* Validate the full certificate chain against the system trust store.
* Reject expired certificates.
* Pin the SHA-256 hash of the root CA or leaf certificate.

If you send confidential data containing personally identifiable information (PII), add application-level encryption and authentication when needed.

### Add RASP protection

Use a commercial Runtime Application Self Protection ([RASP](https://en.wikipedia.org/wiki/Runtime_application_self-protection)) solution.

Detect and respond to:

* Root or jailbreak.
* Debugging.
* Hooking.
* App tampering.
* Emulator execution.

### Logging

Avoid writing sensitive data to device logs.

Use build flags to exclude debug logs from Production Environment builds.

### Adopt secure coding practices

Apply secure coding practices throughout development. For exemple you should:

* perform input validation.
* proper management of memory.
* use secure C functions.
* avoide usage of immutable containers for storing sensitive data.

For a baseline checklist, see OWASP [Secure Coding Practices](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide).

These practices can be enforced using static code analysis tools such as PMD or HP Fortify.

### Perform audits and penetration testing

Perform architecture and code audits, plus penetration testing, to identify vulnerabilities and assessing the overall security posture of the application.

### Evaluate the resilience of application security <a href="#evaluate-the-resilience-of-application-security" id="evaluate-the-resilience-of-application-security"></a>

Check the OWASP MASVS (Mobile Application Security Verification Standard) on [OWASP MASVS](https://github.com/OWASP/owasp-masvs). This is the security requirements baseline for mobile application.

It is highly recommended to use the OWASP MSTG [checklist](https://github.com/OWASP/owasp-mastg/releases/latest) to evaluate the security stature of your application.

## iOS developer security guidelines

### Prevent sensitive data exposure during app lifecycle

Remove sensitive UI content when the app moves to the background.

Wipe or encrypt sensitive data until the app returns to the foreground.

Avoid logging sensitive data.

Use these iOS hooks:

* `applicationWillResignActive`: Clear the screen. Encrypt sensitive data.
* `applicationDidBecomeActive`: Restore the UI. Decrypt sensitive data.
* `UIScreenCapturedDidChangeNotification`: Detect screen capture. Clear sensitive UI content.

Example: hide app content when resigning active.

```swift
UIApplication.shared.keyWindow?.isHidden = true
```

### Remove symbols from Xcode output

For Xcode, set these values in your release build settings:

```
DEPLOYMENT_POSTPROCESSING = YES
GCC_GENERATE_DEBUGGING_SYMBOLS = NO
STRIP_INSTALLED_PRODUCT = YES
STRIP_STYLE = all
COPY_PHASE_STRIP = YES
```

### Manage sensitive data in Swift

Minimize copies of sensitive bytes.

[Data](https://developer.apple.com/documentation/foundation/data) is a value type in Swift. Assigning or passing it can create copies of the underlying bytes.

Pass allocated bytes by reference (using `inout` argument).

```swift
func helloWorld(_ data: inout Data) { 
    ... 
}

var data = Data()
helloWorld(&data)
```

Wipe `Data` after use:

```swift
extension Data {
    internal mutating func wipe() {
        guard count > 0 else {
            return
        }
        let length = count
        withUnsafeMutableBytes { ptr in
            if let mutableRawPtr = ptr.baseAddress {
                memset_s(mutableRawPtr, length, 0, length)
            }
        }
    }
}
```

### Disable auto-correction cache for sensitive input

Disable auto-correction for fields that accept sensitive data.

Use one of these options:

* Set `secureTextEntry = true`.
* Set `autoCorrectionType = UITextAutocorrectionType.no`.

### Disable copy and paste for sensitive input

Disable the copy/paste menu for sensitive fields. This prevents an attacker with access to the device from pasting and viewing the copied data.

```swift
override func canPerformAction(_ action: Selector, withSender sender: Any?) -> Bool {
    let menuController = UIMenuController.shared
    menuController.isMenuVisible = false
    return false
}
```

### Prevent app tampering

Verify app integrity at runtime for sensitive operations.

You can compute the checksum of the `__text` section of the `__TEXT` segment.

For implementation details, see the OWASP MSTG (Mobile Security Testing Guide) guidance on [iOS Anti-Reversing Defenses](https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md).

Use strong obfuscation to protect the checksum implementation.

### Enable Xcode hardening options

Use Xcode settings that make exploitation and reverse engineering harder.

<details>

<summary>Recommended Xcode settings</summary>

```
GCC_UNROLL_LOOPS = YES
GCC_OPTIMIZATION_LEVEL = 3
OTHER_CFLAGS = -fstack-protector-all -finline-functions
CLANG_ENABLE_OBJC_ARC = YES
GCC_DYNAMIC_NO_PIC = NO
LD_NO_PIE = NO
RUN_CLANG_STATIC_ANALYZER = YES
CLANG_ANALYZER_SECURITY_FLOATLOOPCOUNTER = YES
CLANG_ANALYZER_SECURITY_INSECUREAPI_RAND = YES
CLANG_ANALYZER_SECURITY_INSECUREAPI_STRCPY = YES
CLANG_ANALYZER_SECURITY_INSECUREAPI_GETPW_GETS = YES
CLANG_ANALYZER_SECURITY_INSECUREAPI_MKSTEMP = YES
CLANG_ANALYZER_SECURITY_INSECUREAPI_VFORK = YES
```

</details>

## Manage App Store distribution

End users can download an older “last compatible” version of your **digital wallet application**.

Each published version increases your attack surface. Keep the supported version set small.

### Limit downloads of older versions

Disable downloads of previous versions in App Store Connect when possible.

For current Apple behavior and UI labels, see [App Store Connect](https://developer.apple.com/support/app-store-connect/).

{% hint style="info" %}
Remove older versions quickly after you release a security fix.
{% endhint %}

It is recommended to maintain a single, up-to-date version of your digital wallet application. Adjust your build settings to support a broad range of iOS versions.

### Reduce insecure execution environments

Do not distribute simulator builds.

* **Disable the Simulator destination**: The deployment target should only include iOS devices.
* **Disable “Apple Silicon Mac Availability” in App Store Connect**: Running an iOS application on mac M1 increases exposure of the application binary and sandbox.

For details, see Apple guidance on [running your iOS apps on macOS](https://developer.apple.com/documentation/apple-silicon/running-your-ios-apps-on-macos).

## Application protections

Harden the digital wallet application during build and distribution. Focus on sideloading, cloning, and runtime tampering.

### Validate the execution environment

* Ensure that the App is executed on the target devices with SDK supported OS version, firmware version, hardware version.
* Block execution on emulators and jailbroken devices.&#x20;

  See OWASP MSTG guidance on [iOS Anti-Reversing Defenses](https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md).

### Control distribution channels

Distribute the digital wallet application only through official stores and verified channels.

* The application must verify it was installed from the intended store.
* Do not allow side-channel distribution.

### Enforce security updates (force application update)

Ensure a forced application update in case of security fixes.

* Block access to the service when the installed version is below the minimum allowed version.

### Detect tampering, resigning, and cloning

* Detect code signature changes (re-signing) and repackaging.
* Detect modifications of the application binary and resources.
  * See OWASP MSTG guidance on [iOS Anti-Reversing Defenses](https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md)
* Bind sensitive application data to a specific device.

When you detect compromise, please ensure the related account is blacklited and transactions are refused.

### Protect data in transit

* Use TLS 1.2 or TLS 1.3 for all connections to the issuer backend.
* If you implement certificate pinning, plan for certificate rotation.
* Use strong cipher suites and reject weak negotiation.
* Add application-level encryption when required.

### Add runtime protections (RASP)

Ensure that Runtime Application Self Protection is available in the digital wallet application. Detect debugging and hooking during sensitive operations.

* See OWASP MSTG guidance on [iOS Anti-Reversing Defenses](https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06j-Testing-Resiliency-Against-Reverse-Engineering.md)

## Protect assets

This section outlines best practices in app development to protect assets.

#### FCM registration token

If the digital wallet application manages FCM at the app level:

* Avoid persisting the FCM registration token longer than necessary.
* Ensure confidentiality and integrity of this asset.

#### Funding card information

If the digital wallet application collects payment card data:

* Disable risky `UITextField` features, such as AutoFill and copy/paste.
* Use a secure keypad.
* Validate inputs before use.
* Do not store payment card data persistently.
* Before showing the input screen, enforce runtime checks (jailbreak, hooking, debugging, and tampering detection).
* Ensure confidentiality and integrity of this asset.

Apply the same controls to any other sensitive input sourced outside the app.

#### App signing certificate and TLS certificate

* Control access to the app signing certificate.
* Do not disclose it to non-trusted parties.
* Ensure confidentiality and integrity of this asset.

#### Other sensitive assets

* Obfuscate code and protect sensitive strings shipped in the binary.
* Reassess assets on every release (new features could add new sensitive data).
  * Assess the value and criticality of each asset and apply the required protection.
* Do not persist transient data. Clear sensitive data from memory when no longer needed.
* Always consider the device untrusted. Use RASP to help protect the application binary and third-party libraries at runtime.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.payments.thalescloud.io/nfc-wallet-sdk-ios/security-and-privacy/security-guidance.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.