Copyright © 2024 the Contributors to the Web NFC API Security and Privacy Considerations Specification, published by the Web NFC Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.
This document provides a collection of security and privacy related topics concerning web pages and applications using Near Field Communication (NFC). More information about Web NFC can be found in the Web NFC API specification.
This specification was published by the Web NFC Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.
This document provides background for security and privacy related decisions for the Web NFC API. Comments on the document should be filed as issues at https://github.com/w3c/web-nfc/issues.
If you wish to make comments regarding this document, please send them to public-web-nfc@w3.org (subscribe, archives).
For NFC terminology, please consult the Web NFC specification.
The term
browsing context refers to the environment in which
Document objects are
presented to the user. A given browsing context has a single
origin and a single WindowProxy object, but it
can have many Document objects, with their associated
Window objects. The browsing context identifies
the entity which invokes this API, which can be a web app, a
web page, or an
iframe.
The term origin is defined in [HTML5].
The term ASCII serialized origin is defined in [HTML5].
NFC stands for Near Field Communications, short-range wireless technology operating at 13.56 MHz which enables communication between devices at a distance less than 10 cm.
An NFC adapter is the software entity in the underlying platform which provides access to NFC functionality implemented in a given hardware element (NFC chip). A device may have multiple NFC adapters, for instance a built-in one, and one attached via USB.
An NFC tag is a passive NFC device. The NFC tag is powered by magnetic induction when an active NFC device is in proximity range. An NFC tag contains a single NDEF message.
An NFC peer is an active, powered device, which can interact with other devices in order to exchange data using NFC.
An NFC device is either an NFC peer, or an NFC tag.
An NDEF message encapsulates one or more application-defined NDEF records. NDEF is an abbreviation for NFC Forum Data Exchange Format, a lightweight binary message format. NDEF messages can be stored on an NFC tag or exchanged between NFC-enabled devices.
An NDEF record has a maximum payload of 2^32-1 bytes. The record also contains information about the payload size, type, and an optional identifier. NFC Forum standardized a small set of useful data types to be used in NDEF records, for instance text, URL, and binary data such as media. In addition, there are record types designed for more complex interactions, such as Smart Poster, and handover records.
Part of the NDEF record is the NDEF Id field, which may or may not be present. If present, it contains a maximum 256 octets long string which is a URL and it is used for identifying the payload, in an application specific way.
The term NFC content is a synonym for NDEF message, which can originate either from an NFC tag or an NFC peer.
The term Web NFC origin is the ASCII serialized origin of the browsing context that has written the Web NFC message.
The Web NFC Id is a special URL stored in the Web NFC record, and it is used for matching NFC content with URL patterns specified by listeners. For more details see the Web NFC Id section.
A Web NFC record is a special NDEF record which identifies Web NFC content meant for web pages, rather than generic NFC content. For a detailed description see the Web NFC record section.
A Web NFC message represents a set of the NDEF records from a given NDEF message and a special Web NFC record. For more details see the Web NFC Message format section.
The term Web NFC content denotes all Web NFC messages contained in an NDEF message. This version of the specification supports one Web NFC message per NDEF message.
The term trusted integrity NFC content refers to an NDEF message, or an NDEF record, which can be trusted for data integrity, i.e. the content is not changed by third party between writing and reading.
The key security related definitions are the following.
The term expressed permission refers to an act by the user, e.g. via user interface or setting or host device platform features, using which the user approves the permission of a browsing context to access the given functionality.
The term ask for forgiveness refers to some form of unobtrusive notification that informs the user of an operation while it is running. User agents SHOULD provide the user with means to ignore similar future operations from the same origin and advertise this to the user.
The term prearranged trust relationship means that the user agent has already established a trust relationship for a certain operation using a platform specific mechanism, so that an expressed permission from the user is not any more needed. See also the Prearranged trust relationship section.
The term obtain permission for a certain operation indicates that the user agent has either obtained expressed permission, or asks for forgiveness, or ensured a prearranged trust relationship exists.
NFC technology involves multiple levels of security. Payments done with NFC are considered to be at least as secure as with payment cards at hardware level, but the whole software stack needs to be security hardened. However, data transfer (reads, writes and push) involve more threats. This document discusses some of the relevant threats and possible remedies, as input to API design and implementation decisions.
Discussions in issues such as in Verify security model, Suggest a permission UI flow, and Simplify process for obtaining permissions make it clear that NFC technology has a few peculiarities with regards to content handling. In summary,
For instance malicious 3rd parties can write arbitrary URL's into the NDEF Id field or to the Web NFC Id, and inject a prepared attack vector as data to services which use the Web NFC API as well.
Web pages using the NFC API are not trusted. This means that the user needs to be aware of exactly what a web page is intending to do with NFC at any given moment. Also, implementations should make sure that when the user authorizes an NFC operation, then only that action is run, without side effects, and exactly in the context and the number of times the user allows the execution of NFC operations.
Web apps installed from a store, or web pages installed to home screen (with [MANIFEST]) MAY be considered trusted by the user agent.
The following patterns have been considered:
| Threat | Comments, possible mitigation |
|---|---|
| Web page using the Web NFC API collects user data without the consent of the user. | The user SHOULD be able to be aware of what data can be shared using NFC from the given web page. Use permissions and user prompts for accessing personal data, minimize user data exposed to NFC. |
| Malicious web page overwrites tags without user consent. | Make sure the write is additive to previous content. Or, require permission and user prompt needed for writing tags. Or, control what tags can be written by a given web page, for instance a web page can write only a tag which can be connected to its origin. Or, allow overwriting since tags not meant to be written can be protected by making them read only. |
| Malicious web page writes sensitive user data to tags and peer devices. | The user should be able to be aware of what data can be shared using NFC from the given web page. Use permission/user prompt for writing tags and peers. |
| Malicious tag may be involuntarily or voluntarily read by devices and the data read may constitute an attack vector on the user agent. | This is a generic problem with all existing NFC tags. The data is considered application specific. Implementations need security hardening. Involuntary touch is low probability due to short range and critical angle for reading. It’s easier to attack elsewhere (e.g. WiFi and Bluetooth). |
| Malicious smart poster tag attempts triggering an action on the device which may be a threat. | Support for smart posters is not among the main use cases of Web NFC; if and when supported, no automatic actions should be allowed, the user must be made aware and given the ability to control what is happening during the NFC communication. |
| Malicious Web NFC tag could send an arbitrary payload to a website via a user’s device, along with a user’s existing web credentials. The webapp and server would need to treat that payload as completely untrusted. | Suggest rules for handling payload safely, provide best-practice methods for doing so, provide a sanitization/validation function. Payload MAY be even cryptographically signed before writing it to a tag so the contents could later be verified. |
| A Web NFC tag could be used for leaking the user’s location, if the reading triggers a user’s device to navigate to a website. | A Web NFC tag SHOULD NOT ever trigger a user’s device to navigate to a website without asking permission, unless the site has been in the foreground or has been brought to the foreground and has been granted permission. |
In order to minimize attack surface using the Web NFC API, user agents MAY implement multiple security policies, for example some of the following:
In order to support security policies concerning the Web NFC API, certain mechanisms are recommended for the implementations, such as:
In order to obtain permission to a Web NFC function, either an expressed permission is needed (essentially a user prompt or setting), or the functionality has such low security and privacy impact that displaying information about the ongoing operation is considered enough (also known as ask for forgiveness), or then a prearranged trust relationship MUST be established by using specific mechanisms of the underlying platform, and by choices made in the implementation of the user agent. A few examples for prearranged trust relationship are given below.
Web apps installed from a store, or web pages installed to home screen (with [MANIFEST]) MAY be considered trusted by the user agent. In this case the trust concerns the client web page, but not to the date exchanged through NFC.
For trusting the integrity of the data exchanged via NFC, user agents MAY use encrypted NFC content with key management based on Public Key Infrastructure. Key management is out of the scope of the Web NFC specification.
When the risk of 3rd party native applications modifying and faking tags is considered a problem deferred to native application stores, just like the issue whether the user can trust a browser implementation or not, then in this case user agents MAY make the choice of trusting the data content of NFC tags and peers, and this MAY be considered a prearranged trust relationship in the Web NFC API. In that case, user agents MAY consider the Web NFC Id and the Web NFC record as trusted information, so that origin based browser security policies MAY be based on them. Specifically, user prompting policies MAY be relaxed when the origin of the browsing context requesting the Web NFC functionality is equal to the the one saved in the Web NFC Id and optionally when it matches the URL patterns saved in the access control list of Web NFC record payload. This kind of prearranged trust relationship can be applied in the case when the user agent wants to minimize or eliminate user prompts involved in obtaining permissions, and is able to mitigate the involved risks in other ways.
The editors would like to express their gratitude to Jonas Sicking and Jeffrey Yasskin for the initiating thoughts, and to Elena Reshetova and Sandeep Tamrakar for reviews and valuable suggestions.