Prüfaspekte

Artikel basierend auf Abfragen

Alle Prüfaspekte mit Prüftiefe Check
Alle Prüfaspekte mit Prüftiefe Examine
Alle Prüfaspekte mit Prüftiefe CHECK und Building Tool "Make"
Alle Prüfsaspekte mit der Programmiersprache "Python"
Alle Prüfsaspekte, die ein Framework nutzen

angelegte Artikel

1. O.Arch 9 (Beschreibung: Die Web-Anwendung SOLL HTTP-Server-Header nutzen, die dem aktuellen Stand der Technik entsprechen und die Sicherheit der Anwendung erhöhen. Dazu gehören unter anderem HTTP Strict Transport Security (HSTS), Content Security Policy (CSP) und X-Frame-Options.)
2. O.Auth 3 (Beschreibung: Jeder Authentifizierungsvorgang des Nutzers MUSS in Form einer Zwei-Faktor-Authentifizierung umgesetzt werden.)
3. O.Cryp 1 (Beschreibung: Beim Einsatz von Verschlüsselung in der Web-Anwendung DÜRFEN KEINE fest einprogrammierten geheimen, bzw. privaten Schlüssel eingesetzt werden.)
4. O.Source 1 (Beschreibung: Die Anwendung MUSS Eingaben aus nicht vertrauenswürdigen Quellen vor deren Verwendung prüfen, um potenziell bösartige Werte vor der Verarbeitung herauszufiltern.)
5. O.TrdP 1 (Beschreibung: Der Hersteller MUSS eine zentrale und vollständige Liste von Abhängigkeiten durch externe Software, Bibliotheken und Frameworks führen.)

Anwendungszweck

1. O.Purp 1 (Beschreibung: Der Hersteller MUSS die rechtmäßigen Zwecke der Web-Anwendung und die Verwendung von personenbezogenen Daten offenlegen (etwa in der Beschreibung der Nutzungsbedingungen der Web-Anwendung) und den Nutzer spätestens bei der erstmaligen Nutzung der Anwendung darüber informieren.)
2. O.Purp 2 (Beschreibung: Die Web-Anwendung DARF KEINE Daten erheben und verarbeiten, die nicht dem rechtmäßigen Zweck der Anwendung dienen.)
3. O.Purp 3 (Beschreibung: Die Web-Anwendung MUSS vor jeglicher Erfassung oder Verarbeitung personenbezogener aktive und eindeutige Einwilligungserklärung des Nutzers einholen.)
4. O.Purp 4 (Beschreibung: Daten, deren Verwendung der Nutzer nicht ausdrücklich zugestimmt hat, DÜRFEN NICHT von der Web-Anwendung oder dem Hintergrundsystem erfasst oder genutzt werden.)
5. O.Purp 5 (Beschreibung: Die Web-Anwendung MUSS ermöglichen, dass der Nutzer eine bereits erteilte Einwilligung wieder entziehen kann. Der Nutzer MUSS vor der Einwilligung über die Möglichkeit des Widerrufs und die sich daraus ergebenden Veränderungen im Verhalten der Anwendung informiert werden.)
6. O.Purp 6 (Beschreibung: Der Hersteller MUSS ein Verzeichnis führen, welches erkennen lässt, welche Nutzereinwilligungen vorliegen. Der nutzerspezifische Teil des Verzeichnisses MUSS für den Nutzer automatisiert einsehbar sein.)
7. O.Purp 8 (Beschreibung: Sofern es nicht für den vorgesehenen primären Zweck einer Web-Anwendung erforderlich ist, DÜRFEN sensible Daten NICHT mit Dritten geteilt werden. Die Anwendung MUSS den Nutzer über die Konsequenzen einer eventuellen Weitergabe von Anwendungsdaten vollumfänglich informieren und sein Einverständnis einholen (OPT-IN).)
8. O.Purp 9 (Beschreibung: Die Web-Anwendung DARF sensible Daten NICHT auf dem Bildschirm darstellen, außer dies ist für den primären Zweck der Anwendung erforderlich.)

Architektur

1. O.Arch 1 (Beschreibung: „Security“ MUSS ein fester Bestandteil des Softwareentwicklungs- und Lebenszyklus‘ für die gesamte Web-Anwendung und das Hintergrundsystem sein.)
2. O.Arch 2 (Beschreibung: Bereits in der Designphase von Web-Anwendung und Hintergrundsystem MUSS berücksichtigt werden, dass die Anwendung in der Produktivphase sensible Daten verarbeiten wird. Die Architektur der Anwendung MUSS dafür die sichere Erhebung, Verarbeitung, Speicherung und Löschung der sensiblen Daten in einem Datenlebenszyklus abbilden.)
3. O.Arch 3 (Beschreibung: Der Lebenszyklus von kryptographischem Schlüsselmaterial MUSS einer ausgearbeiteten Richtlinie folgen, die Eigenschaften wie die Zufallszahlenquelle, detaillierte Angaben zur Aufgabentrennung von Schlüsseln, Ablauf von Schlüsselzertifikaten, Integritätssicherung durch Hash-Algorithmen etc., umfasst. Die Richtlinie SOLL auf anerkannten Standards wie TR02102-2 und NIST80057 basieren.)
4. O.Arch 4 (Beschreibung: Backups und Cloud-Backups DÜRFEN KEINE sensiblen Daten im Klartext beinhalten. Die Web-Anwendung muss daher so gestaltet sein, dass sensible Daten auch durch den Browser nicht etwa in dessen Cache persistiert werden.)
5. O.Arch 6 (Beschreibung: Die Architektur der Web-Anwendung SOLL einem minimalistischen Ansatz folgen und mit einer serverseitig lokalisierten Verarbeitungslogik realisiert sein, d.h. es SOLLEN keine komplexen aktiven Inhalte (Java Applets, ActiveX-Plugin, o.ä.) verwendet werden.)
6. O.Arch 7 (Beschreibung: Der Hersteller MUSS dem Nutzer eine barrierearme Möglichkeit bereitstellen, um Sicherheitsprobleme zu melden. Die Kommunikation SOLL über einen verschlüsselten Kanal stattfinden.)
7. O.Arch 8 (Beschreibung: Das Hintergrundsystem MUSS beim Start auf die Aktualität des genutzten Web-Browsers prüfen. Wenn die Installation eines sicherheitsrelevanten Updates noch nicht erfolgt ist, DARF das Hintergrundsystem KEINEN Zugriff auf sensible Daten ermöglichen.)
8. O.Arch 9 (Beschreibung: Die Web-Anwendung SOLL HTTP-Server-Header nutzen, die dem aktuellen Stand der Technik entsprechen und die Sicherheit der Anwendung erhöhen. Dazu gehören unter anderem HTTP Strict Transport Security (HSTS), Content Security Policy (CSP) und X-Frame-Options.)

Quellcode

1. O.Source 1 (Beschreibung: Die Anwendung MUSS Eingaben aus nicht vertrauenswürdigen Quellen vor deren Verwendung prüfen, um potenziell bösartige Werte vor der Verarbeitung herauszufiltern.)
2. O.Source 2 (Beschreibung: Die Anwendung MUSS eingehende und ausgehende Daten maskieren beziehungsweise von potenziell schadhaften Zeichen bereinigen oder deren Verarbeitung ablehnen.)
3. O.Source 4 (Beschreibung: Potenzielle Ausnahmen im Programmablauf (Exceptions) MÜSSEN abgefangen, kontrolliert behandelt und dokumentiert werden. Technische Fehlerbeschreibungen (z.B. Stack Traces) DÜRFEN dem Nutzer NICHT angezeigt werden.)
4. O.Source 5 (Beschreibung: Bei Ausnahmen im Programmablauf (Exceptions), mit sicherheitskritischen Auswirkungen, SOLL die Web-Anwendung Zugriffe auf sensible Daten abbrechen und diese im Speicher sicher löschen.)
5. O.Source 6 (Beschreibung: Alle Optionen zur Unterstützung der Entwicklung (z. B. Log-Aufrufe, Entwickler-URLs, Testmethoden etc.) MÜSSEN in der Produktiv-Version mindestens deaktiviert oder besser vollständig entfernt sein.)
6. O.Source 7 (Beschreibung: Der Hersteller MUSS sicherstellen, dass keinerlei Überreste von Debug-Mechanismen in der Produktiv-Version verbleiben.)
7. O.Source 8 (Beschreibung: Nutzt die Web-Anwendung URL-Weiterleitungen (URL-Redirects), MUSS diese kontrolliert erfolgen.)
8. O.Source 9 (Beschreibung: Die Web-Anwendung MUSS Maßnahmen vorsehen, die verhindern, dass Funktionalitäten, die nicht in der Entwicklungshoheit des Herstellers liegen, in die Web-Anwendung eingeschleust und zur Ausführung gebracht werden.)

Drittanbieter-Software

1. O.TrdP 1 (Beschreibung: Der Hersteller MUSS eine zentrale und vollständige Liste von Abhängigkeiten durch externe Software, Bibliotheken und Frameworks führen.)
2. O.TrdP 2 (Beschreibung: Externe Software, Bibliotheken und Frameworks MÜSSEN in der neusten oder der ihr vorhergehenden, verfügbaren „Stable“ -Version verwendet werden.)
3. O.TrdP 3 (Beschreibung: Externe Bibliotheken und Frameworks MÜSSEN durch den Hersteller regelmäßig auf Schwachstellen überprüft werden. Der Hersteller MUSS ein Sicherheitskonzept vorlegen, das bei Bekanntwerden von Schwachstellen anhand der Kritikalität eine geduldete Weiternutzung für die Anwendung festlegt. Nachdem die Übergangsfrist (Grace Period) abgelaufen ist, DÜRFEN die betroffenen Funktionen aus Bibliotheken und Frameworks bei bekannten Schwachstellen NICHT eingesetzt werden.)
4. O.TrdP 4 (Beschreibung: Sicherheitsupdates für externe Bibliotheken und Frameworks MÜSSEN zeitnah zur Verfügung gestellt werden. Der Hersteller MUSS ein Sicherheitskonzept vorlegen, das anhand der Kritikalität ausnutzbarer Schwachstellen die geduldete Weiternutzung für die Web-Anwendung, bzw. das Hintergrundsystem festlegt. Nachdem die Übergangsfrist (Grace Period) abgelaufen ist, DARF die Web-Anwendung NICHT mehr zur Benutzung angeboten werden.)
5. O.TrdP 5 (Beschreibung: Vor der Verwendung von externen Bibliotheken und Frameworks MUSS deren Quelle auf Vertrauenswürdigkeit geprüft werden. Die Web-Anwendung DARF externe Libraries aus nicht-vertrauenswürdigen Quellen NICHT nachladen.)
6. O.TrdP 6 (Beschreibung: Über Drittanbieter-Software eingehende Daten SOLLEN validiert werden.)

Kryptographische Umsetzung

1. O.Cryp 1 (Beschreibung: Beim Einsatz von Verschlüsselung in der Web-Anwendung DÜRFEN KEINE fest einprogrammierten geheimen, bzw. privaten Schlüssel eingesetzt werden.)
2. O.Cryp 2 (Beschreibung: Die Anwendung MUSS auf bewährte Implementierungen zur Umsetzung krypto-graphischer Primitive und Protokolle zurückgreifen.)
3. O.Cryp 3 (Beschreibung: Die Wahl kryptographischer Primitive MUSS passend zum Anwendungsfall sein und dem aktuellen Stand der Technik entsprechen.)
4. O.Cryp 4 (Beschreibung: Kryptographische Schlüssel DÜRFEN NICHT für mehr als genau einen Zweck eingesetzt werden.)
5. O.Cryp 5 (Beschreibung: Die Stärke der kryptographischen Schlüssel MUSS dem aktuellen Stand der Technik entsprechen.)

Authentifizierung

1. O.Auth 1 (Beschreibung: Der Hersteller MUSS ein Konzept zur Authentifizierung (Zwei-Faktor-basiert), Autorisierung (Rollenkonzept) und zum Beenden einer Anwendungssitzung dokumentieren.)
2. O.Auth 10 (Beschreibung: Der Nutzer MUSS in den Nutzungsbedingungen der Web-Anwendung auf das Restrisiko hingewiesen werden, welches mit der Speicherung der Login-Credentials im Web- Browser oder auch einem anderen externen Programm für einen komfortableren Anmeldevorgang verbunden ist.)
3. O.Auth 11 (Beschreibung: Für die Nutzer-Authentifizierung in der Anwendungssitzung KANN der zweite Faktor vom Hintergrundsystem-System erzeugt werden.)
4. O.Auth 2 (Beschreibung: Die Web-Anwendung MUSS für die Anbindung an das Hintergrundsystem eine geeignete Authentifizierung und Autorisierung unterstützen. Die effektive Durchsetzung dieser Mechanismen MUSS im Falle der Web-Anwendung ausschließlich im Hintergrundsystem erfolgen. Insbesondere stellt der Autorisierungsmechanismus sicher, dass der authentifizierte Benutzer autorisiert ist auf die sensiblen Daten zuzugreifen.)
5. O.Auth 3 (Beschreibung: Jeder Authentifizierungsvorgang des Nutzers MUSS in Form einer Zwei-Faktor-Authentifizierung umgesetzt werden.)
6. O.Auth 4 (Beschreibung: Für die Bewertung eines Authentifizierungsvorgangs SOLLEN zusätzliche Informationen (z. B. das verwendete Endgerät, der verwendete IP-Adresse oder die Zeit des Zugriffs) mit einbezogen werden.)
7. O.Auth 5 (Beschreibung: Dem Nutzer SOLL eine Möglichkeit gegeben werden, sich über ungewöhnliche Anmeldevorgänge informieren zu lassen.)
8. O.Auth 6 (Beschreibung: Die Anwendung MUSS nach einer angemessenen Zeit in der sie nicht aktiv verwendet wurde (idle time) eine erneute Authentisierung fordern.)
9. O.Auth 7 (Beschreibung: Die Anwendung MUSS nach einer angemessenen Zeit in der sie aktiv verwendet wurde (active time) eine erneute Authentisierung fordern.)
10. O.Auth 8 (Beschreibung: Die Authentisierungsdaten DÜRFEN NICHT ohne eine ausreichende Authentifizierung des Nutzers geändert werden.)
11. O.Auth 9 (Beschreibung: Bei Änderung der Zugangsparameter SOLL der Nutzer über die zuletzt hinterlegten, gültigen Kontaktdaten über die Änderung informiert werden. Dem Nutzer SOLL über diesem Weg eine Möglichkeit geboten werden, die gemeldete Änderung zu sperren und nach entsprechender Authentifizierung neue Zugangsparameter zu setzen.)

Authentifizierung über Passwort

1. O.Pass 1 (Beschreibung: Bei einer Authentifizierung mittels Benutzername und Passwort MÜSSEN starke Passwortrichtlinien existieren. Diese SOLLEN sich am aktuellen Stand gängiger Best-Practices orientieren.)
2. O.Pass 2 (Beschreibung: Für die Authentifizierung mittels Benutzername und Passwort KANN die Stärke des verwendeten Passworts dem Nutzer angezeigt werden. Informationen über die Stärke des gewählten Passworts DÜRFEN NICHT in der Web-Anwendung oder im Hintergrundsystem persistiert werden.)
3. O.Pass 3 (Beschreibung: Der Nutzer MUSS die Möglichkeit haben, sein Passwort zu ändern.)
4. O.Pass 4 (Beschreibung: Das Ändern und Zurücksetzen von Passwörtern MUSS protokolliert werden)

Zustandsbezogene Authentifzierungsmaßnahmen

1. O.Sess 1 (Beschreibung: Das Session-Handling SOLL mittels sicherer Frameworks realisiert werden.)
2. O.Sess 2 (Beschreibung: Der Session-Identifier SOLL in einem sicheren Speicherbereich liegen.)
3. O.Sess 3 (Beschreibung: Die Anwendung MUSS es dem Nutzer ermöglichen einen oder alle zuvor ausgestellten Session-Identifier ungültig zu machen.)
4. O.Sess 4 (Beschreibung: Wird eine Anwendungssitzung beendet, MUSS die Anwendung den Session-Identifier sicher löschen und das Hintergrundsystem informieren. Dies gilt sowohl für das aktive Beenden durch den Benutzer (log-out), als auch für das automatische Beenden durch die Anwendung (vgl. O.Auth_6 und O.Auth_7).)

Zustandslose Authentifzierungsmaßnahmen

1. O.Tokn 1 (Beschreibung: Das Authentifizierungstoken MUSS in einem sicheren Speicherbereich liegen (vgl. O.Sess_2).)
2. O.Tokn 2 (Beschreibung: Es DÜRFEN KEINE sensiblen Daten in ein Authentifizierungstoken eingebettet werden.)
3. O.Tokn 3 (Beschreibung: Ein Authentifizierungstoken MUSS ausschließlich die von der Web-Anwendung erwarteten Felder enthalten.)
4. O.Tokn 4 (Beschreibung: Die Web-Anwendung MUSS es dem Nutzer ermöglichen ein oder alle zuvor ausgestellten Authentifizierungstoken ungültig zu machen.)
5. O.Tokn 5 (Beschreibung: Wird eine Anwendungssitzung beendet, MUSS die Anwendung den Authentifizierungstoken sicher löschen und das Hintergrundsystem informieren. Dies gilt sowohl für das aktive Beenden durch den Benutzer (log-out), als auch für das automatische Beenden durch die Anwendung.)

Datensicherheit

1. O.Data 1 (Beschreibung: Die Voreinstellung der Web-Anwendung MUSS die maximale Sicherheit bieten.)
2. O.Data 10 (Beschreibung: Sensible Daten DÜRFEN NICHT aus der Komponente, auf der sie erzeugt wurden, exportiert werden.)
3. O.Data 11 (Beschreibung: Durch die Web-Anwendung kann der Zugriff für Dritte und die Speicherung des Bildschirms (z. B. Screenshots und Anzeigen für das App-Switching) nicht unterbunden werden. Über die Nutzungsbedingungen MUSS der Nutzer darüber informiert werden, dass sensible Daten über Screenshots oder Anzeigen für das App-Switching kompromittiert werden können.)
4. O.Data 12 (Beschreibung: Über die Nutzungsbedingungen der Web-Anwendung MUSS der Nutzer über das Risiko informiert werden, welches damit verbunden ist, dass im gesperrten Zustand des Endgeräts die Verbindung zum Hintergrundsystem weiter geöffnet bleibt, wenn der Nutzer sich nicht explizit ausgeloggt hat.)
5. O.Data 13 (Beschreibung: Die Web-Anwendung SOLL sicherstellen, dass bei ihrer Beendigung alle sensiblen Daten und anwendungsspezifischen Anmeldeinformationen im Web-Browser nicht mehr zugreifbar sind. Dies schließt insbesondere Cookies und Webstorage mit ein.)
6. O.Data 14 (Beschreibung: Die Web-Anwendung MUSS dem Nutzer die Möglichkeit geben, dass bei endgültiger Beendigung der Nutzung alle sensiblen Daten und anwendungsspezifischen Anmeldeinformationen auch im Hintergrundsystem vollständig gelöscht werden. Entscheidet sich der Nutzer, die Daten im Hintergrundsystem nicht zu löschen, MUSS eine für den primären Zweck angemessene maximale Verweildauer definiert sein. Der Nutzer MUSS über die Verweildauer informiert werden. Nach Ablauf der maximalen Verweildauer MÜSSEN alle sensiblen Daten und anwendungsspezifischen Anmeldeinformationen vollständig gelöscht werden. Dem Nutzer MUSS die Möglichkeit gegeben werden alle Daten auch vor Ablauf der Verweildauer vollständig zu löschen.)
7. O.Data 15 (Beschreibung: Für alle Cookies, auf die nicht mittels JavaScript zugegriffen wird, MUSS das HTTP-Only-Flag verwendet werden.)
8. O.Data 16 (Beschreibung: Für alle Cookies, die sensible Daten enthalten, MUSS das Secure-Flag gesetzt sein.)
9. O.Data 17 (Beschreibung: Für alle Formularfelder mit sensiblen Eingabedaten MUSS die Autocomplete-Funktion abgeschaltet sein.)
10. O.Data 18 (Beschreibung: Im Browser persistierte Daten SOLLEN für weitere Hosts einer Domain unlesbar sein (d.h. Vermeidung von Domain-Cookies).)
11. O.Data 2 (Beschreibung: Exportiert der Nutzer sensible Daten unverschlüsselt MUSS der Nutzer durch die Web-Anwendung darauf aufmerksam gemacht werden, dass der Nutzer selbst die Verantwortung für die Datensicherheit dieser exportierten Daten übernimmt.)
12. O.Data 3 (Beschreibung: Die Web-Anwendung DARF Ressourcen, die einen Zugriff auf sensible Daten ermöglichen, gegenüber Dritten NICHT verfügbar machen.)
13. O.Data 4 (Beschreibung: Alle erhobenen sensiblen Daten DÜRFEN NICHT über die Dauer ihrer jeweiligen Verwendung hinaus in der Web-Anwendung gehalten werden.)
14. O.Data 5 (Beschreibung: Die Web-Anwendung MUSS die Grundsätze der Datensparsamkeit und Zweckbindung berücksichtigen.)
15. O.Data 7 (Beschreibung: Bei der Verwendung von Aufnahmegeräten (z. B. Kamera) MÜSSEN sämtliche Metadaten mit Datenschutz-Relevanz, wie etwa Rückschlüsse auf die GPS-Koordinaten des Aufnahmeorts, eingesetzte Hardware etc., entfernt werden.)
16. O.Data 8 (Beschreibung: Bei der Erhebung von sensiblen Daten durch die Verwendung von Aufnahmegeräten (z.B. Kamera), MUSS vorgebeugt werden, dass andere Anwendungen darauf Zugriff erlangen könnten, etwa über eine Mediengalerie.)
17. O.Data 9 (Beschreibung: Bei der Eingabe sensibler Daten über die Tastatur SOLL die Web-Anwendung unterbinden, dass Aufzeichnungen für Dritte erkennbar werden.)

Kostenpflichtige Ressourcen

1. O.Paid 1 (Beschreibung: Die Web-Anwendung MUSS für den Nutzer kenntlich machen, welche kostenpflichtigen Leistungen (z.B. Zusatzfunktionalitäten oder Premiumzugriffe) und welche kostenpflichtigen Ressourcen (z.B. SMS, Telefonate, mobile Daten) von der Anwendung angeboten oder verwendet werden.)
2. O.Paid 10 (Beschreibung: Zahlverfahren von Drittanbietern MÜSSEN die Anforderungen an Drittanbieter-Software erfüllen (vgl. Kapitel 3.1.4).)
3. O.Paid 2 (Beschreibung: Die Web-Anwendung MUSS vor dem Ausführen kostenpflichtiger Leistungen das Einverständnis des Nutzers einholen.)
4. O.Paid 3 (Beschreibung: Die Web-Anwendung MUSS vor einer Zugriffsanforderung auf kostenpflichtige Ressourcen, das Einverständnis des Nutzers einholen.)
5. O.Paid 4 (Beschreibung: Die Web-Anwendung KANN für den Zugriff auf häufig verwendete, kostenpflichtige Ressourcen oder kostenpflichtige Leistungen ein dauerhaftes Einverständnis des Nutzers einholen, soweit dies dem primären Zweck der Anwendung angemessen ist.)
6. O.Paid 5 (Beschreibung: Die Web-Anwendung MUSS den Nutzer in die Lage versetzen, zuvor erteilte Einverständnisse zurückzuziehen.)
7. O.Paid 6 (Beschreibung: Die Anwendung SOLL die Transaktionshistorie von kostenpflichtigen Leistungen im Hintergrundsystem ablegen. Die Transaktionshistorie, einschließlich der Metadaten, MUSS als sensibles Datum gemäß O.Purp_8 behandelt werden.)
8. O.Paid 7 (Beschreibung: Falls die Web-Anwendung kostenpflichtige Funktionen anbietet, MUSS der Hersteller ein Konzept vorlegen, welches vorbeugt, dass Dritte die Zahlungsströme zur Nutzung von Anwendungsfunktionen zurückverfolgen können.)
9. O.Paid 8 (Beschreibung: Die Web-Anwendung MUSS dem Nutzer eine Übersicht der entstandenen Kosten anbieten. Falls die Kosten aufgrund einzelner Zugriffe erfolgt sind, MUSS die Anwendung einen Überblick der Zugriffe aufführen.)
10. O.Paid 9 (Beschreibung: Die Validierung von getätigten Bezahlvorgängen MUSS im Hintergrundsystem vorgenommen werden.)

Netzwerkkommunikation

1. O.Ntwk 1 (Beschreibung: Jegliche Netzwerkkommunikation der Web-Anwendung MUSS durchgängig mit TLS verschlüsselt werden.)
2. O.Ntwk 2 (Beschreibung: Die Konfiguration der TLS-Verbindungen MUSS dem aktuellen Stand der Technik entsprechen und aktuellen Best-Practice-Empfehlungen folgen.)
3. O.Ntwk 3 (Beschreibung: Die Web-Anwendung MUSS die Sicherheitsfunktionalität der jeweilig verwendeten Betriebssystem-Plattform mit Browser verwenden, um sichere Kommunikationskanäle aufzubauen.)
4. O.Ntwk 4 (Beschreibung: Die Web-Anwendung DARF Zertifikate NICHT akzeptieren, deren Zertifikatskette dem Hersteller nicht vertrauenswürdig erscheint.)

Plattformspezifische Interaktionen

1. O.Plat 1 (Beschreibung: Für die Nutzung der Web-Anwendung SOLL das Endgerät über einen aktivierten Geräteschutz (Passwort, Mustersperre, o. ä.) verfügen. Im Fall eines nicht aktivierten Geräteschutzes MUSS der Hersteller den Nutzer über die damit verbundenen Risiken aufklären.)
2. O.Plat 2 (Beschreibung: Die Web-Anwendung DARF Berechtigungen, die für die Erfüllung ihres primären Zwecks nicht notwendig sind, NICHT einfordern.)
3. O.Plat 3 (Beschreibung: Die Web-Anwendung MUSS den Nutzer auf den rechtmäßigen Zweck der anzufragenden Berechtigungen und auf die Auswirkungen hinweisen, die eintreten, falls der Nutzer diese nicht gewährt.)
4. O.Plat 4 (Beschreibung: Die Web-Anwendung DARF KEINE sensiblen Daten in erweiterten Meldungen oder Benachrichtigungen, die nicht vom Nutzer explizit eingeschaltet wurden (siehe O.Plat_5),anzeigen.)
5. O.Plat 5 (Beschreibung: Die Web-Anwendung KANN dem Nutzer die Optionen bieten, erweiterte Meldungen und Benachrichtigungen zum Logging bzw. zur Fehleranalyse, ggf. auch mit sensiblen Inhalten, anzuzeigen. Bei Werkseinstellung MUSS diese deaktiviert sein.)
6. O.Plat 6 (Beschreibung: Die Web-Anwendung MUSS das Ausführen von JavaScript aus Quellen außerhalb der Kontrolle des Herstellers ablehnen.)
7. O.Plat 7 (Beschreibung: Die Web-Anwendung MUSS den Nutzer über das Risiko informieren, dass ggf. nach Beendigung der Web-Anwendung nutzerspezifischen Daten im Arbeitsspeicher verbleiben können.)
8. O.Plat 8 (Beschreibung: Der Nutzer MUSS über Sicherheitsmaßnahmen informiert werden, sofern diese durch den Nutzer umsetzbar sind.)

Resilienz

1. O.Resi 1 (Beschreibung: Die Web-Anwendung MUSS dem Nutzer barrierearme Best-Practice-Empfehlungen zum sicheren Umgang mit der Anwendung und ihrer Konfiguration bereitstellen.)
2. O.Resi 2 (Beschreibung: Die Web-Anwendung MUSS über die Nutzungsbedingungen dem Nutzer darstellen, welche Risiken für die Daten des Nutzers bei einer Benutzung von Geräten mit Jailbreak oder Root-Zugriff bestehen (z. B. dass diese offengelegt werden könnten).)