#Issue50
3 posts

We crashed and lost all essential data logs. Where did we go wrong?

Enforce a 7-day-timeframe complete log check. Mandate daily monitoring of logs at the end of each day.
Read more

We crashed and lost all essential data logs. Where did we go wrong?

How to prevent such a loss?

  • Enforce a 7-day-timeframe complete log check.
  • Mandate daily monitoring of logs at the end of each day. Team members can rotate through this role for a daily check and a 2-week sprint.
  • Require a minimum of two approvals per pull request.
  • Use a refactoring approach for writing tests - if a test fails, reverse your last change and implement it in a way that does not break the test, changing the code only one line at a time.
  • For flows of code that are harder to cover with unit tests, you may need a hybrid of unit &integration tests.

Full post here, 7 mins read

Don’t just check errors, handle them gracefully

Best option to use is an opaque error strategy that requires the least coupling between code and caller. The caller only knows an error happened, but they can’t see inside the error.
Read more

Don’t just check errors, handle them gracefully

  • There are three core strategies for error handling in Go.
  • Sentinel errors return a specific value. In error type handling, you create a type that implements the error interface. Error types are better than sentinel errors because they capture more context about what went wrong.
  • But both sentinel & error types error handling become part of your public API. And they create source code dependency between the caller and the package that implements the error interface. Both ate best avoided
  • Best option to use is an opaque error strategy that requires the least coupling between code and caller. The caller only knows an error happened, but they can’t see inside the error.
  • Consider using an error package with two main functions - ‘wrap’ to take an error & a message to produce a new error; the second is ‘cause’ which takes the possibly wrapped error and unwraps it to discover the original issue.
  • Only handle an error once. Inspect the error value and make a decision. No decision means the error is not handled.

Full post here, 11 mins read

The most common types of ATO attacks

ATO (account takeover) attacks are dangerous because when your system thinks the attacker is a legitimate user, your security safeguards won’t be able to protect your system.
Read more

The most common types of ATO attacks

  • ATO (account takeover) attacks are dangerous because when your system thinks the attacker is a legitimate user, your security safeguards won’t be able to protect your system.
  • Credential stuffing uses lists of common passwords & email addresses/usernames in random pairs to ‘stuff’ the website.
  • In brute-force attacks, the attacker tries a variety of passwords for a given username, usually attempting to compromise specific valuable accounts, such as admin accounts.
  • In a dictionary attack, attackers precompute information about commonly used passwords and then try to obtain an encrypted password by using a large set of words from the dictionary to generate potential passwords.
  • Phishing is when an attacker poses as you to get the user to disclose their credentials. The best way to prevent phishing is customer education.

Full post here, 6 mins read