For protections against vulnerabilities, there are pros and cons to either platform. While both share the same core issue of the exploitation of an application vulnerability. Since either platform is effectively utilizing an application that permits access to read the parsed email text messages.
First and foremost which application, be it browser or email client, is the crux of determining exposure to vulnerabilities. Such as with ECMAScript in the case of the browser (Safari vs Internet Explorer vs FireFox) or parsing of mail headers in the case of an email client (Lotus Notes vs Outlook vs Firebird).
Email Client Applications
The biggest drawback of any email client, is that the entire email body and attachments are downloaded to the local machine prior to being parsed & viewed. This poses serious security concerns with the parsing methods, as this could lead to the email client executing a payload without user consent.
One example is the KAK virus that used Javascript which would execute without user interaction when the preview option was enabled (default) in Outlook Express, IE was used to render the preview, exploiting a safe-scripting policy between IE and Outlook Express.
Consistency within the application provides a unified display of the content, regardless of the email service provider, which can give a false sense of security as user account settings or emails/spam are not filtered identically across providers.
Email clients are also the most common avenue of spreading viruses from an infected system. Since the virus typically will have access to process and send emails to your contacts as if it were from your physical machine/network.
From a system admin perspective, the MBOX, PST (MS Disclaimer), or similar email archive file will be persisted and accessible as a local system file. Granting the ability for a malicious actor to obtain the archive of downloaded messages from the file, circumventing the requirement for email account owner credentials.
Webmail or Browser Based Email
Vulnerabilities within the browser, its addons/plugins/extensions and the webmail provider (Gmail, Outlook, Yahoo) are the main points of entry.
Unlike email client apps, most modern day browsers utilize sandboxing which isolates malicious activity to only be able to interact with the DOM, preventing any access to the local system files or the OS API. However, plugins installed in the browser can extend the scope of exploitation, leading to exposure to the local system files and OS API through the plugin.
Major examples that were commonly exploited are IE with ActiveX/Silverlight and any browser using NPAPI (Netscape Plugin API) with Java or Flash - which has since been deprecated and should no longer be used.
On the webmail service provider's end, it would depend on whether images and scripts are allowed to be loaded/run when (pre)viewing the message/subject within the UI. The vast majority of email service providers remove these types elements from the UI asking for consent prior to allowing them. While others also use a proxy URL to the resources, reducing the exposure to advertisements and tracking techniques, allowing the provider to blacklist the original resource URL.
Attachments and External Links/Access
The common issues between webmail and email clients are the UI parsing and user-interaction of the email messages.
Opening an attachment or clicking on an external-link in a message would typically yield the same results in either the browser or email client app.
It is also important to note that NO ATTACHMENT (even images, word documents, videos, PDF, etc) should be considered "safe". All of them are susceptible to exploitation of vulnerabilities, even from trusted sources. Prime examples are the Melissa virus (contained in a Word Document) and the RCE buffer-overflow vulnerability (affected by JPEGs). Just because it hasn't happened yet doesn't mean it is not possible, that is not out in the wild, or that it happened and was unnoticed. Zero-day vulnerabilities, like the printer-spool exploit, are constantly being announced.
Account Hijacking/Unauthorized Access
Another shared cause for concern is user account hijacking. Since both require a username and password of an account holder to gain access, it exposes the potential for unauthorized access of a user's account, such as by compromised credentials, brute-force, or unattended system access.
Depending on the service provider, account access can be protected by implementing region-based security policies, forced logout periods, password expirations, strict password complexity requirements, and most notably Multi-Factor Authentication.
Take Away
Which is safest ultimately depends on necessity.
If it is imperative to limit browser access or have a set standardization for a global hub of signatures, contacts, calendars, and emails with shared inboxes that can be proceduralized. Then a standardized email client is easily deployable within an organization with group policies and automation. Features which are lacking from most webmail providers - though is slowly being improved upon.
If work is predominantly performed within a browser, there is no real benefit to force the usage of an email client over webmail. Since the end-user will be exposed to the same threats regardless.
