This is an automated email from the ASF dual-hosted git repository.
github-bot pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cordova-docs.git
The following commit(s) were added to refs/heads/asf-site by this push:
new c3d11e54c5 Deploying to asf-site from @
apache/cordova-docs@6bd4ffa0f3ebf61f84744e7566e3902391ad689b π
c3d11e54c5 is described below
commit c3d11e54c5e24c4a6bf4a7710b73937e3823d159
Author: erisu <er...@users.noreply.github.com>
AuthorDate: Tue Mar 18 02:10:36 2025 +0000
Deploying to asf-site from @
apache/cordova-docs@6bd4ffa0f3ebf61f84744e7566e3902391ad689b π
---
docs/en/dev/guide/appdev/allowlist/index.html | 69 +++++++++++-
docs/en/dev/guide/appdev/security/index.html | 153 +++++++++++++++++++-------
feed.xml | 4 +-
3 files changed, 183 insertions(+), 43 deletions(-)
diff --git a/docs/en/dev/guide/appdev/allowlist/index.html
b/docs/en/dev/guide/appdev/allowlist/index.html
index 39e9c8846c..e46947aee7 100644
--- a/docs/en/dev/guide/appdev/allowlist/index.html
+++ b/docs/en/dev/guide/appdev/allowlist/index.html
@@ -2425,7 +2425,7 @@
to the host, or as a suffix to the path --></span>
<span class="nt"><allow-navigation</span> <span
class="na">href=</span><span class="s">"*://*.example.com/*"</span> <span
class="nt">/></span>
-<span class="c"><!--
+<span class="c"><!--
A wildcard can be used to allow the entire network, over HTTP and HTTPS.
This is *NOT RECOMMENDED*
--></span>
@@ -2480,10 +2480,63 @@
<h2>Content Security Policy (CSP)</h2>
-<p>Controls which network requests (images, XHRs, etc) are allowed to be made
(via webview directly).</p>
+<p>The <a
href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP";><strong>Content
Security Policy (CSP)</strong></a> <code><meta></code> tag is a very
powerful mechanism that allows you to control trusted sources of content. You
can restrict various content types and domains from which content can be loaded
from. Unsafe and risky HTML and JavaScript can also be disabled to further
increase the security of your app.</p>
+
+<p>The CSP <code><meta></code> tag should be placed in your app's
index.html file.</p>
<p>On Android and iOS, the network request allow list (see above) is not able
to filter all types of requests (e.g. <code><video></code> &
WebSockets are not blocked). So, in addition to the allow list, you should use
a <a href="http://content-security-policy.com/";>Content Security Policy</a>
<code><meta></code> tag on all of your pages.</p>
+<blockquote>
+ <p><strong>Note</strong>: If your app has multiple HTML files and navigates
between them using the browser's navigation features, you should include
the CSP in each file. If your app is a single-page application, you only need
to include the CSP on <code>index.html</code>.</p>
+</blockquote>
+
+<h3>Cordova's Default Template Content Security Policy</h3>
+
+<p>The CSP that Cordova's default template uses looks like this (indented
for clarity):</p>
+
+<div class="language-html highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="nt"><meta</span> <span
class="na">http-equiv=</span><span class="s">"Content-Security-Policy"</span>
+ <span class="na">content=</span><span class="s">"default-src 'self' data:
https://ssl.gstatic.com 'unsafe-eval';
+ style-src 'self' 'unsafe-inline';
+ media-src *;
+ img-src 'self' data: content:;"</span><span class="nt">></span>
+</code></pre></div></div>
+
+<p>The above snippet enforces the following:</p>
+
+<p><strong>Default Source (<code>default-src</code>):</strong></p>
+
+<p>As a fallback, all other network requests are restricted to:</p>
+
+<ul>
+ <li>The same origin as the app itself (<code>'self'</code>).</li>
+ <li>Resources loaded via <code>data:</code> URIs.</li>
+ <li>Resources from the specified external domain
<code>https://ssl.gstatic.com</code>.</li>
+ <li>JavaScript methods such as <code>eval()</code> (and similar) are
permitted with <code>'unsafe-eval'</code>.</li>
+</ul>
+
+<p><strong>Style Source (<code>style-src</code>):</strong></p>
+
+<ul>
+ <li>Styles can only be loaded from the same origin
(<code>'self'</code>).</li>
+ <li>Inline styles (<code>'unsafe-inline'</code>) are also allowed, meaning
styles can be directly applied using the <code>style</code> attribute on
elements or within <code><style></code> tags.</li>
+</ul>
+
+<p><strong>Media Source (<code>media-src</code>):</strong></p>
+
+<ul>
+ <li>Media can be loaded from any source.</li>
+</ul>
+
+<p><strong>Image Source (<code>img-src</code>):</strong></p>
+
+<ul>
+ <li>Images can only be loaded from the same origin
(<code>'self'</code>).</li>
+ <li>Allows loading images from <code>data:</code> URIs.</li>
+ <li>Allows loading images from <code>content:</code> URIs, typically used
within the Android ecosystem.</li>
+</ul>
+
+<h3>Example Content Security Policy Declarations</h3>
+
<p>Here are some example CSP declarations for your <code>.html</code>
pages:</p>
<div class="language-html highlighter-rouge"><div class="highlight"><pre
class="highlight"><code><span class="c"><!-- Good default declaration:
@@ -2497,7 +2550,7 @@
<span class="c"><!-- Allow everything but only from the same origin and
foo.com --></span>
<span class="nt"><meta</span> <span class="na">http-equiv=</span><span
class="s">"Content-Security-Policy"</span> <span
class="na">content=</span><span class="s">"default-src 'self'
foo.com"</span><span class="nt">></span>
-<span class="c"><!-- This policy allows everything (eg CSS, AJAX, object,
frame, media, etc) except that
+<span class="c"><!-- This policy allows everything (eg CSS, AJAX, object,
frame, media, etc) except that
* CSS only from the same origin and inline styles,
* scripts only from the same origin and inline styles, and eval()
--></span>
@@ -2510,6 +2563,16 @@
<span class="nt"><meta</span> <span class="na">http-equiv=</span><span
class="s">"Content-Security-Policy"</span> <span
class="na">content=</span><span class="s">"default-src 'self'; frame-src 'self'
https://cordova.apache.org";</span><span class="nt">></span>
</code></pre></div></div>
+<p>You should fully understand the CSP tag and the various directives that can
be specified. More documentation is available at <a
href="https://web.dev/articles/csp";>Content Security Policy</a> (via Google
Developers) and Mozilla's <a
href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP";>Content Security
Policy (CSP)</a> article.</p>
+
+<blockquote>
+ <p><strong>Tip</strong>: If you're using web sockets, include
<code>ws:</code> (<code>wss:</code> if using SSL) in the
<code>connect-src</code> directive.</p>
+</blockquote>
+
+<h3>Debugging Content Security Policy</h3>
+
+<p>When adding a CSP to your app, it's likely you'll encounter some
issues. Fortunately, both Google Chrome's Developer Tools and Safari's
Web Inspector make it very clear when a CSP violation occurs. Watch the console
for any violation messages, which are typically quite detailed, specifying
exactly which resource was blocked and why. Address each violation as they
appear to ensure your CSP is properly configured.</p>
+
<h2>Other Notes</h2>
<p><a
href="https://developer.apple.com/library/prerelease/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW33";>Application
Transport Security (ATS)</a> is new in iOS 9 (Xcode 7). This new feature acts
as an allow list for your app. Cordova CLI will automatically convert the
<code><access></code> and <code><allow-navigation></code> tags to
the appropriate ATS directives.</p>
diff --git a/docs/en/dev/guide/appdev/security/index.html
b/docs/en/dev/guide/appdev/security/index.html
index e5aed977ee..a1ef68e63f 100644
--- a/docs/en/dev/guide/appdev/security/index.html
+++ b/docs/en/dev/guide/appdev/security/index.html
@@ -2369,28 +2369,85 @@
<h2>This guide discusses the following topics:</h2>
<ul>
+ <li>General Tips</li>
+ <li>Plugins and Security</li>
<li>Allow List</li>
- <li>Iframes and the Callback Id Mechanism</li>
+ <li>Content Security Policy</li>
<li>Certificate Pinning</li>
- <li>Self-signed Certificates</li>
+ <li>Using TLS/SSL</li>
+ <li>Avoid Self-signed Certificates</li>
+ <li>Wrapping external sites and hot code push</li>
<li>Encrypted storage</li>
- <li>General Tips</li>
<li>Recommended Articles and Other Resources</li>
</ul>
+<h2>General Tips</h2>
+
+<h3>Use InAppBrowser for outside links</h3>
+
+<p>Use the <a
href="https://www.npmjs.com/package/cordova-plugin-inappbrowser";>InAppBrowser</a>
when opening links to any outside website. This is much safer than allow
listing a domain name and including the content directly in your application
because the InAppBrowser will use the native browser's security features
and will not give the website access to your Cordova environment. Even if you
trust the third party website and include it directly in your application, that
third party [...]
+
+<h3>Validate all user input</h3>
+
+<p>Always validate any and all input that your application accepts. This
includes usernames, passwords, dates, uploaded media, etc. Because an attacker
could manipulate your HTML and JS assets (either by decompiling your
application or using debugging tools like <code>chrome://inspect</code>), this
validation should also be performed on your server, especially before handing
the data off to any backend service.</p>
+
+<blockquote>
+ <p><strong>Tip</strong>: Other sources where data should be validated: user
documents, contacts, push notifications</p>
+</blockquote>
+
+<h3>Do not store sensitive data</h3>
+
+<p>If usernames, password, geolocation information, and other sensitive data
is stored, then it could potentially be retrieved later by an unauthorized user
or application.</p>
+
+<h3>Don't use <code>eval()</code></h3>
+
+<p>The JavaScript function <code>eval()</code> has a long history of being
abused. Using it incorrectly can open your code up for injection attacks,
debugging difficulties, and slower code execution.</p>
+
+<h3>Do not assume that your source code is secure</h3>
+
+<p>Since a Cordova application is built from HTML and JavaScript assets that
get packaged in a native container, you should not consider your code to be
secure. It is possible for an iOS or Android application to be unpacked and
unzipped to reveal its web assets such as HTML and JS.</p>
+
+<p>A sampling of what you should not include in your code:</p>
+
+<ul>
+ <li>Authentication information (usernames, passwords, keys, etc.)</li>
+ <li>Encryption keys</li>
+ <li>Trade secrets</li>
+</ul>
+
+<h3>Do not assume storage containers are secure</h3>
+
+<p>Even if a device itself is encrypted, if someone has access to the device
and can unlock it, you should not assume that data stored in various formats
and containers is safe. Even SQLite databases are easily human readable once
access is gained.</p>
+
+<p>As long as you're storing non-sensitive information, this isn't a
big deal. But if you were storing passwords, keys, and other sensitive
information, the data could be easily extracted, and depending on what was
stored, could be used against your app and remote servers.</p>
+
+<p>For example, on iOS, if you store data in <code>localStorage</code>, the
data itself is easily readable to anyone who has access to the device. This is
because <code>localStorage</code> is backed by an unencrypted SQLite database.
The underlying storage of the device may in fact be encrypted (and so it would
be inaccessible while the device is locked), but once the device decrypts the
file, the contents themselves are mostly in the clear. As such, the contents of
<code>localStorage</c [...]
+
+<h2>Plugins and Security</h2>
+
+<p>Due to the way the native portion of Cordova communicates with your web
code, it is possible for any code executing within the main webview context to
communicate with any installed plugins. This means that you should
<em>never</em> permit untrusted content within the primary webview. This can
include third-party advertisements, sites within an <code>iframe</code>, and
even content injected via <code>innerHTML</code>.</p>
+
+<p>If you must inject content into the primary webview, be certain that it has
been properly sanitized so that no JavaScript can be executed. <em>Do not try
to sanitize content on your own; use a vetted third-party library
instead!</em></p>
+
+<blockquote>
+ <p><strong>Tip</strong>: If you need to include advertising, use any of the
many third-party plugins for Cordova. These are safer than executing arbitrary
JavaScript from advertisers.</p>
+</blockquote>
+
<h2>Allow List</h2>
<p>By default the app's navigation is unrestricted. It's recommended
to restrict the navigation only to trusted domains. Learn more by reading the
<a href="../allowlist/index.html">Allow List Guide</a></p>
-<h2>Iframes and the Callback Id Mechanism</h2>
+<h2>Content Security Policy (CSP)</h2>
-<p>If content is served in an iframe from a allow listed domain, that domain
will have access to the native Cordova bridge. This means that if you allow a
third-party advertising network and serve those ads through an iframe, it is
possible that a malicious ad will be able to break out of the iframe and
perform malicious actions. Because of this, you should generally not use
iframes unless you control the server that hosts the iframe content. Also note
that there are third party plugins [...]
+<p>Cordovaβs default template includes a basic Content Security Policy (CSP).
Itβs recommended to review and customize this CSP to fit your app's
specific needs. For more information, refer to the <a
href="../allowlist/index.html#content-security-policy-csp">Allow List Guide -
Content Security Policy (CSP)</a>.</p>
<h2>Certificate Pinning</h2>
-<p>Cordova does not support true certificate pinning. The main barrier to this
is a lack of native APIs in Android for intercepting SSL connections to perform
the check of the server's certificate. (Although it is possible to do
certificate pinning on Android in Java using JSSE, the webview on Android is
written in C++, and server connections are handled for you by the webview, so
it is not possible to use Java and JSSE there.) Since Apache Cordova is meant
to offer consistent APIs a [...]
+<p>It is important to ensure that you trust any hosts with which there are
communications. Typically, one would do this using certificate pinning. The app
would double check any certificates and only communicate over channels where
the certificate check passed. This helps mitigate man-in-the-middle attacks.</p>
+
+<p>Unfortunately, Cordova does not support true certificate pinning. The main
barrier to this is a lack of native APIs in Android for intercepting SSL
connections to perform the check of the server's certificate. (Although it
is possible to do certificate pinning on Android in Java using JSSE, the
webview on Android is written in C++, and server connections are handled for
you by the webview, so it is not possible to use Java and JSSE there.) Since
Apache Cordova is meant to offer co [...]
-<p>There are ways to approximate certificate pinning, such as checking the
server's public key (fingerprint) is the expected value when your
application starts or at other various times during your application's
lifetime. There are third-party plugins available for Cordova that can do that.
However, this is not the same as true certificate pinning which automatically
verifies the expected value on every connection to the server.</p>
+<p>There are ways to approximate certificate pinning, such as checking that
the server's public key (fingerprint) is the expected value when your
application starts or at other various times during your application's
lifetime. There are third-party plugins available for Cordova that can do that.
However, this is not the same as true certificate pinning which automatically
verifies the expected value on every connection to the server.</p>
<p>There are also plugins that can do true certificate pinning for some
platforms, assuming your app is able to do all of its network requests using
the plugin (i.e.: no traditional XHR/AJAX requests, etc).</p>
@@ -2398,66 +2455,86 @@
<p>If your app communicates to an external server, it should be communicating
using modern encryption standards. Use <code>https</code> protocol whenever
possible.</p>
-<p><a href="https://letsencrypt.org/";>Let's Encrypt</a> is a free,
automated, and open certificate authority provided by the nonprofit <a
href="https://www.abetterinternet.org/";>Internet Security Research Group</a>.
Let's Encrypt will offer free standard certificates, which will be
sufficient for most developers. Enterprise organizations may still want to use
a traditional certificate authority that offers more advanced features such as
<a href="https://en.wikipedia.org/wiki/Publ [...]
+<p><a href="https://letsencrypt.org/";>Let's Encrypt</a> is a free,
automated, and open certificate authority provided by the nonprofit <a
href="https://www.abetterinternet.org/";>Internet Security Research Group</a>.
Let's Encrypt will offer free standard certificates, which will be
sufficient for most developers. Enterprise organizations may still want to use
a traditional certificate authority that offers more advanced features such as
<a href="https://en.wikipedia.org/wiki/Publ [...]
<p>It is also important to keep up to date with security standards as they
change over time. What might be acceptable SSL/TLS configuration today may not
be acceptable years in the future. Using tools to test your certificate and
SSL/TLS configuration should be done regularly. <a
href="https://www.ssllabs.com/ssltest/";>SSL Labs</a> is a free online service
provided by Qualys, Inc to test your server's SSL/TLS configuration and
encryption strength, in addition to supported platforms.</p>
-<h2>Self-signed Certificates</h2>
+<h2>Avoid Self-signed Certificates</h2>
-<p>Using self-signed certificates on your server is not recommended. If you
desire SSL, then it is highly recommended that your server have a certificate
that has been properly signed by a well-known CA (certificate authority). The
inability to do true certificate pinning makes this important.</p>
+<p>Using self-signed certificates on your server is not recommended. If you
desire SSL, then it is highly recommended that your server have a certificate
that has been properly signed by a well-known CA (certificate authority). The
inability to do true certificate pinning makes this even more important.</p>
-<p>The reason is that accepting self-signed certificates bypasses the
certificate chain validation, which allows any server certificate to be
considered valid by the device. This opens up the communication to
man-in-the-middle attacks. It becomes very easy for a hacker to not only
intercept and read all communication between the device and the server, but
also to modify the communication. The device will never know this is happening
because it doesn't verify that the server's cer [...]
+<p>The reason is that accepting self-signed certificates bypasses the
certificate chain validation, which allows any server certificate to be
considered valid by the device. This opens up the communication to
man-in-the-middle attacks. It becomes very easy for a hacker to not only
intercept and read all communication between the device and the server, but
also to modify the communication. The device will never know this is happening
because it doesn't verify that the server's cer [...]
-<p>If the application is to be used only within a trusted network, such as an
internal corporate network. Using self-signed certificates may be acceptable,
however the public certificate should be pre-installed on the device(s) that
will be running the application. A trusted third-party certificate authority
will always be preferable.</p>
+<p>Because of the ease of doing a man-in-the-middle attack, accepting
self-signed certificates is only marginally better than just running
<code>http</code> instead of <code>https</code> on an untrusted network. While
the traffic would be encrypted, it could be encrypted with the key from a
man-in-the-middle, so the man-in-the-middle would have access everything,
making the encryption useless except to passive observers. Users trust SSL to
be secure, and this would be deliberately making [...]
-<p>The principles described here are not specific to Apache Cordova, they
apply to all client-server communication.</p>
+<p>If the app will be used on a trusted network (i.e., you are entirely inside
a controlled enterprise), then self-signed certs are still not recommended. The
two recommendations in a trusted network are to just use http because the
network itself is trusted, or to get a certificate signed by a trusted CA (not
self-signed). Either the network is trusted or it is not.</p>
-<p>When running Cordova on Android, using
<code>android:debuggable="true"</code> in the application manifest will permit
SSL errors such as certificate chain validation errors on self-signed certs. So
you can use self-signed certs in this configuration, but this is not a
configuration that should be used when your application is in production. It is
meant to be used only during application development.</p>
+<blockquote>
+ <p><strong>Note</strong>: The principles described here are not specific to
Apache Cordova, they apply to all client-server communication.</p>
+</blockquote>
-<h2>Encrypted storage</h2>
+<blockquote>
+ <p><strong>Android Tip</strong>: When running Cordova on Android, using
<code>android:debuggable="true"</code> in the application manifest will permit
SSL errors such as certificate chain validation errors on self-signed certs. So
you can use self-signed certs in this configuration, but this is not a
configuration that should be used when your application is in production. It is
meant to be used only during application development.</p>
+</blockquote>
-<p>(TBD)</p>
+<h2>Wrapping external sites and hot code push</h2>
-<h2>General Tips</h2>
+<p>Cordova's implementation allows you to redirect to an external site
instead of using local content. This is <strong>not</strong> suggested for most
apps, even though it might avoid a rewrite of the app or can make code updates
faster. You should avoid this for any apps destined to any app store, but in
general, it's risky regardless, for many reasons:</p>
-<h3>Do not use Android Gingerbread!</h3>
<ul>
- <li>Set your min-target-sdk level higher than 10. API 10 is Gingerbread, and
Gingerbread is no longer supported by Google or device manufacturers, and is
therefore not recommend by the Cordova team.</li>
- <li>Gingerbread has been shown to be insecure and one of the most targeted
mobile OSs <a
href="https://bgr.com/2012/11/06/android-security-gingerbread-malware/";>https://www.mobilemag.com/2012/11/06/andriod-2-3-gingerbread-security/</a>.</li>
- <li>The Allowlist on Android does not work with Gingerbread or lower. This
means an attacker can load malicious code in an iframe that would then have
access to all of the Cordova APIs and could use that access to steal personal
data, send SMS messages to premium-rate numbers, and perform other malicious
acts.</li>
+ <li>No local code to detect no route to host. Apple <em>requires</em> apps
to detect no network connection (and other connectivity issues) and display a
user-friendly error message. If there's no local code to detect this, the
app will generally remain blank, and Apple will reject it.</li>
+ <li>No local code to verify the downloaded content. The content could be
incomplete or corrupted, especially if being downloaded over a poor network
connection. Incomplete or corrupt content is not going to render particularly
well, leaving your user frustrated.</li>
+ <li>No local code to detect and remove malicious intent. Local code has a
chance to sanitize content and verify that there are no spurious or unexpected
<code>script</code> tags or event handlers. Without local code, the app is at
the server's mercy.</li>
+ <li>No local code to check certificates. See <strong>Certificate
Pinning</strong> above.</li>
</ul>
-<h3>Use InAppBrowser for outside links</h3>
-<ul>
- <li>Use the InAppBrowser when opening links to any outside website. This is
much safer than allow listing a domain name and including the content directly
in your application because the InAppBrowser will use the native browser's
security features and will not give the website access to your Cordova
environment. Even if you trust the third party website and include it directly
in your application, that third party website could link to malicious web
content.</li>
-</ul>
+<p>Hot code push solutions improve matters a bit, since they will download
code and store it locally on the device. This means that in the event of a
network failure, the code still has a chance to run and display any appropriate
messages, and that same code can verify any future downloads. You should,
however, verify that any hot code push service you use does the following:</p>
-<h3>Validate all user input</h3>
<ul>
- <li>Always validate any and all input that your application accepts. This
includes usernames, passwords, dates, uploaded media, etc. Because an attacker
could manipulate your HTML and JS assets (either by decompiling your
application or using debugging tools like chrome://inspect), this validation
should also be performed on your server, especially before handing the data off
to any backend service.</li>
- <li>Other sources where data should be validated: user documents, contacts,
push notifications</li>
+ <li>Validate checksums to ensure complete and accurate downloads</li>
+ <li>Certificate checking to ensure that the download is from a trusted
server</li>
+ <li>Falls back to last downloaded code in the event something goes wrong</li>
</ul>
-<h3>Do not cache sensitive data</h3>
-<ul>
- <li>If usernames, password, geolocation information, and other sensitive
data is cached, then it could potentially be retrieved later by an unauthorized
user or application.</li>
-</ul>
+<h2>Encrypted Storage</h2>
+
+<p>Both <strong>Android</strong> and <strong>iOS</strong> offer various secure
storage options. While <strong>Apache Cordova</strong> does not provide these
mechanisms natively at the platform core or plugin level, third-party plugins
may be available or can be created to implement such features.</p>
+
+<p><strong>Android:</strong></p>
-<h3>Don't use eval() unless you know what you're doing</h3>
<ul>
- <li>The JavaScript function eval() has a long history of being abused. Using
it incorrectly can open your code up for injection attacks, debugging
difficulties, and slower code execution.</li>
+ <li>
+ <p><a
href="https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences";><strong>Encrypted
Shared Preferences</strong></a></p>
+
+ <p><strong>Encrypted SharedPreferences</strong> is an encrypted version of
SharedPreferences, where both the keys and values are encrypted. This is ideal
for storing small amounts of data, such as user settings, preferences, or other
sensitive information.</p>
+ </li>
+ <li>
+ <p><a
href="https://developer.android.com/reference/androidx/security/crypto/EncryptedFile";><strong>Encrypted
File Storage</strong></a></p>
+
+ <p><strong>Encrypted File Storage</strong> is suitable for securely
storing files, perfect for large data. By using the <code>EncryptedFile</code>
class, you can create and read encrypted files, ensuring that the file contents
remain protected.</p>
+ </li>
</ul>
-<h3>Do not assume that your source code is secure</h3>
+<p><strong>iOS:</strong></p>
+
<ul>
- <li>Since a Cordova application is built from HTML and JavaScript assets
that get packaged in a native container, you should not consider your code to
be secure. It is possible to reverse engineer a Cordova application.</li>
+ <li>
+ <p><strong>File Protection</strong></p>
+
+ <p>Using <a
href="https://developer.apple.com/documentation/foundation/nsfilemanager";><code>NSFileManager</code></a>,
which provides an interface for managing the file system, you can define a
file's protection level with the <a
href="https://developer.apple.com/documentation/foundation/nsfileprotectiontype";><code>NSFileProtectionType</code></a>
attribute. This allows you to store files on disk with protection based on the
device's lock state. Files are encrypted and accessib [...]
+ </li>
+ <li>
+ <p><a
href="https://developer.apple.com/documentation/security/keychain-services?language=objc";><strong>Keychain
Services</strong></a></p>
+
+ <p><strong>Keychain Services</strong> is a secure method for storing small
pieces of sensitive data, such as passwords or tokens. Data in the keychain is
encrypted and protected by the device's security mechanisms.</p>
+ </li>
</ul>
<h2>Recommended Articles and Other Resources</h2>
<ul>
- <li><a
href="https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet";>HTML5
Security cheat sheet, detailing how to secure your HTML5 application</a></li>
- <li><a
href="http://www.cis.syr.edu/~wedu/Research/paper/webview_acsac2011.pdf";>Whitepaper
about well known security flaws in Webview based hybrid applications</a></li>
+ <li><a
href="https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html";>OWASP
Cheat Sheet Series - HTML5 Security Cheat Sheet</a></li>
+ <li><a
href="https://www.cs.ucr.edu/~heng/pubs/webview_acsac2011.pdf";>Research Paper -
Attacks on WebView in the Android System</a></li>
</ul>
diff --git a/feed.xml b/feed.xml
index 5b7bb1d6ea..4a43643ee8 100644
--- a/feed.xml
+++ b/feed.xml
@@ -6,8 +6,8 @@
</description>
<link>https://cordova.apache.org/</link>
<atom:link href="https://cordova.apache.org/feed.xml"; rel="self"
type="application/rss+xml"/>
- <pubDate>Tue, 18 Mar 2025 02:06:12 +0000</pubDate>
- <lastBuildDate>Tue, 18 Mar 2025 02:06:12 +0000</lastBuildDate>
+ <pubDate>Tue, 18 Mar 2025 02:09:44 +0000</pubDate>
+ <lastBuildDate>Tue, 18 Mar 2025 02:09:44 +0000</lastBuildDate>
<generator>Jekyll v4.4.1</generator>
<item>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cordova.apache.org
For additional commands, e-mail: commits-h...@cordova.apache.org
