paul/flow-hugo
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Publishing pre-reqs part 2

Browse Source
This commit is contained in:
paul
2024-01-10 14:01:47 -05:00
parent b78805b312
commit 5a5564b770
1 changed files with 13 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
content/posts/code-complete-summations-pre-requisets-part-2.md
View File

@@ -1,7 +1,7 @@
---
title: "Pre-Requisites (Part II) Initial Design: Code Complete Summations"
date: 2023-12-26
draft: true
draft: false
---
# Introduction
@@ -42,11 +42,22 @@ Creating a skeleton of all the major classes will go a long way to ensuring good
The way the data is designed can have a major impact on security. There are different types of data to consider when designing a secure system. Any data that is considered sensitive, such as PII, should be encrypted both at rest and in transit. Any data that should not be able to be altered by a user should probably also be encrypted both at rest and in transit.
Really all data should be encrypted in transit to reduce the possibility of man-in-the-middle reading or altering the content.
Data that can/should be readable or editable by the user does not need to be encrypted at rest.
All data should be encrypted in transit to reduce the possibility of man-in-the-middle reading or altering the content.
The data design needs to also be agreed upon by all parties using the data. If the design and restrictions are being used differently on both ends, this will cause read/processing errors if both expect different things.
## User Interface
The UI needs to be considered a separate component that uses an API to communicate with the backend. This moduler approach will allow flexibility, as well as naturally leads to security in depth. If the UI is treated separate, then any user input should be sanitized at the UI side. Since it's considered a separate component, then all user input should be sanitized on the backend as well.
## Error Processing and Logging
Here is a big one. Error handling needs to be designed from the beginning. If errors are handled through exceptions, integer returns, parameters passed by reference, etc, this will lead to confusion in the code base and errors will be missed. There should be one design for errors used universally across the project, so all developers know how to handle the errors.
As for logging, this needs to be taken into account for two big reasons. The first is to have the appropriate amount to diagnose and fix errors. The second is how much data and what data will be displayed, as this could lead to unintentionally leaking secure information.
# Conclusion
Having a good design from the beginning can help prevent problems before they even arise. Then if bugs and security issues are found, having a good architecture will help to locate those issues faster.