Skip to content

Commit

Permalink
add some missing texts
Browse files Browse the repository at this point in the history
  • Loading branch information
andreashappe committed Sep 11, 2024
1 parent 4495890 commit 9feaf00
Show file tree
Hide file tree
Showing 2 changed files with 10 additions and 1 deletion.
9 changes: 9 additions & 0 deletions docs/the-top-10/c4-secure-architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,15 @@ There are design principles that lead to secure architectures:
- **Identify and minimize your exposed components** ("attack surface"): attackers cannot attack what's not there.
- **Design for Defense-in-Depth**: think about what happens, if a component is breached and about the potential blast radius of an attack.

### Usage of Third-Party Components such as Libraries and Frameworks

While it might be possible to implement all requirements manually, it is highly recommended to base one's architecture upon established and well-maintained third-party components. This has multiple benefits:

- **Don't reimplement the wheel** and learn from (security) failures of others. Often, existing libraries and frameworks have undergone a security audit and security issues have been identified and eventually remediated. Benefit from the security works of others!
- **Secure Defaults**: more and more frameworks offer defensive and secure defaults. To enable risky behavior, manual developer interaction is needed.
- **But keep them up to date**. While you gain benefits from using maintained frameworks, you know have the maintenance burden of tracking their new releases for security notes.
- **Don't fight the framework**. If using a framework feels like you are fighting it each and every step, then maybe this concrete framework is not a good match for your development style or architecture (or vice versa).

## Threats

- If the application is only protected by security-by-obscurity, an attacker that reverse-engineers the application has full permissions as soon the obfuscation is cleared-up. In addition, an attacker is able to monitor network traffic: while the obfuscation might be performed on the code-level, the operations on the network level can easily be analyzed.
Expand Down
2 changes: 1 addition & 1 deletion docs/the-top-10/c8-leverage-browser-security-features.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@

Browsers are the gateway to the web for most users. As such, it's critical to employ robust security measures to protect the user from various threats. This section outlines the techniques and policies that can be implemented to bolster browser security.

While we are currently focusing upon traditional web browsers, please note that there is a diverse world of other client programs out there, ranging from API clients to smart-TVs.
While we are currently focusing upon traditional web browsers, please note that there is a diverse world of other client programs out there, ranging from mobile apps, API clients to smart-TVs. We encourage to verify what client-side security features are supported by your client and use the respective HTTP headers to configure them.

### Opportunistic Security and Browser-Support

Expand Down

0 comments on commit 9feaf00

Please sign in to comment.