I've been scanning an iOS application of mine and the highest risk vulnerability appears to be that the pasteboard is not getting cleared when I terminate the application. I don't want the user to lose potentially userful information they have copied as a result of over-zealousness especially when the data is still very much insecure when the app has not been terminated and other apps are being run in tandem.

In a similar question to my own but for the windows pasteboard it's suggested this would not be a high risk problem as the pasteboard should be the least of my worries when malware is present on my device. What is the main reason I should be doing this and why is it considered as a fairly high risk?

The app has access to the internet and does contain SPI.

  • What kind of information is accessible in the application? Who will be using the app, and where? Does it have access to the internet? Commented Jan 14, 2016 at 23:43
  • @MarkBuffalo The app will contain the user's name, work location, employee ID, job role, department, manager, user ID, password, user preferences and contact details. For now sales staff within our company will use it, we'll expand this if the app is successful. Commented Jan 19, 2016 at 13:56
  • Do you mean the windows clipboard? The copy and paste stuff? Commented Jan 19, 2016 at 14:12
  • The clipboard for the iPhone. Sorry I really should have mentioned that in the question. Commented Jan 19, 2016 at 15:38

3 Answers 3


When malware is present on the device, indeed, having the pasteboard store this data would be the least of your worries. However, this is still bad practice.

You should not store important user data in the clipboard. You shouldn't even be putting it in the pasteboard/clipboard anyway. Why? Because a malicious application could access your clipboard data. Imagine a website accesses your clipboard (either normally, or through an exploit), or another application stores it and sends it to a remote server?

What if there's a method such as:

sendDataToRemoteServerForPurposesOfExtremeHaxoring(string evilLaugh, string pasteboardData)?

Like so:

// Oh noes!
UIPasteboard *pasteBoard = [UIPasteboard generalPasteboard];
sendDataToRemoteServerForPurposesOfExtremeHaxoring("Mwahahahahaha", pasteBoard.string);

Also, storing a user's password and other critical information in the clipboard is, in my opinion, a huge, huge no-no. What if the user accidentally pastes it? What if an application exploits it? What if a website exploits it? There are a lot of reasons not to do this.

  • "storing a user's password and other critical information in the clipboard is a huge, huge no-no": Yet there are well respected applications like KeePass who store passwords in the clipboard. Are they "huge no-no"? Commented Jan 19, 2016 at 16:20
  • 2
    I added, "in my opinion." I don't use, nor do I trust password managers. This person has critical login information stored, and it could could lead to major breaches. Having access to someone's credentials to get on the corporate VPN and wreck havoc is another example. Commented Jan 19, 2016 at 16:24

The clipboard indeed cannot be considered a safe place, this for several reasons:

  • Malware accessing the clipboard content: in your question you focused on malware installed in your machine, however there could be transient malware (like a malicious Adobe Flash banner on a website you visited for instance...) which will not infect your computer when run, but just attempt to get the clipboard content at that time and send it to their home,

  • User wrong manipulation: A wrong manipulation could lead you to paste the wrong content at the wrong place. Usually without consequences, with sensitive data such wrong manipulation can still have heavy consequences,

  • People around the user: When the computer is left unattended and unlocked or if the user's attention is temporarily distracted, it is very quick for someone else to press a Ctrl-V then Ctrl-Z on his keyboard to quickly see his clipboard content without the user noticing.

While it is still better to avoid completely clipboard usage, when it is required the mitigation for such threat is to ensure that the sensitive data does not remain in the clipboard for too long: ideally it should just remain there enough time to be used and no longer.

In your question you suggest to clear the clipboard when the application exits. The efficiency of this greatly depends on the way the application is used: if this is the kind of application which is closed only at the end of the day such measure seems just ineffective.

An good example and inspirational source for this situation can be the password manager KeePass which proposes to handle this in two ways, depending on user's preferences:

  • To avoid completely clipboard usage, KeePass proposes what it calls Auto-Type: it will directly fill targeted fields by simulating the appropriate key presses. The advantage is that no data ever passes through the clipboard, however such behavior is more complex to implement and may not be fully compatible or portable (especially true since you mention a mobile application),

  • When using the clipboard to copy/paste passwords, KeePass can be configured to automatically clear the clipboard after a short amount of time. When copying a password, KeePass displays at the bottom of its main window a decreasing progress bar giving the user a visual feedback over the timeout progress, and once the timeout expires (15 or 30 seconds for instance) and if the clipboard still contains KeePass data then KeePass deletes the clipboard content (the user must not use one of those "clipboard history managers" for this to be really effective though).

  • Your third bullet point in the first list is a really good point. Ctrl-V then Ctrl-Z. Commented Jan 19, 2016 at 17:12

I am going to focus on the iOS aspect here - other answers do mention things not applicable on iOS (eg. 'Auto-type:'). I am an iOS developer and have worked on 'secure' apps.

Sadly, every "security scanner" I have tried for iOS code is at best what I shall refer to as "highly misleading". I suspect the phrase I would normally use is not family friendly enough for stackexchange.

The "vulnerability" and their suggested mitigation are "highly misleading". It both harms usability, and doesn't help when an iPad is running the app in 'side by side' multitasking, nor in other situation.

As WhiteWinterWolf says, you should consider not letting highly sensitive data onto the system clipboard in the first place if that works for your use case. In iOS, you can implement an internal clipboard to the app, by subclassing UITextField, UITextView (etc) and providing replacements for UIResponderStandardEditActions that do not use the system [UIPasteboard generalPasteboard].

If you have a compelling use case for allowing data to be passed to other applications, as of iOS 10, you can also set UIPasteboardOptionExpirationDate and UIPasteboardOptionLocalOnly (as iOS 10 now shares the clipboard around all devices logged into the same iCloud account by default) to try to limit the exposure.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .