Post-it Code

I recently overheard some users asking about limiting support to TLS 1.3 because it’s a better standard for security. No doubt it is, but in my opinion, if your websites or web services are targeting a global audience, continuing to support TLS 1.2 is a fair and pragmatic choice. TLS 1.3-only policies are safe when the audience is highly targeted and known—such as employees within an organization. Older devices and browsers may still rely on TLS 1.2, and by supporting it, you ensure wider compatibility without sacrificing security. TLS 1.2 remains secure as long as it uses modern ciphers like AES or GCM. By deprecating weak ciphers and enforcing strong configurations, you can still avoid vulnerabilities. Of course, when providing support for TLS 1.2, it’s important to follow a strict security policy: TLS 1.3 must be supported in the security configuration. TLS 1.0 and TLS 1.1 should not be supported, as they are considered insecure. A DevOps friend of mine pointed out that major servic...

While it’s not mandatory, implementing SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) has become common practice to protect your email from spoofing and improve deliverability. However, these alone are not sufficient, as SPF and DKIM do not enforce alignment between the "From" address and the authenticated domain. An attacker can send an email that passes SPF and DKIM checks but uses a different "From" address domain, potentially misleading recipients. To minimize or prevent this scenario, you should enhance your email security by implementing DMARC (Domain-based Message Authentication, Reporting, and Conformance). DMARC policies instruct email providers on how to handle emails that fail DMARC validation, helping to protect your domain from spoofing and phishing attacks. Additionally, DMARC enables you to monitor the actions taken by email providers. Here are the primary DMARC policies: None : Allow the email to be delivered normally, even if it...

Hashing can be a resource-intensive process for many programming languages. If your application has a text input interface that doesn't limit the number of characters, it can be exploited by attackers who supply excessively large inputs. This can potentially slow down your application or, in the worst-case scenario, cripple it entirely—an attack known as a Denial of Service (DoS). To protect your application, always validate and sanitise text input by checking its length before hashing. This simple measure can significantly enhance the security and stability of your application. Disclosure: This entry is based on a collection of my personal notes, and some of the information may be outdated or no longer relevant. If you notice any inaccuracies, please let me know in the comments. I appreciate your feedback and will correct the entry as needed. :)

If you manage applications, you may encounter users who register multiple accounts using variations of the same Gmail address (or other email providers with a similar feature). This allows them to exploit your account creation process without needing to create entirely new email addresses. As Google explains:  Dots don't matter in Gmail addresses Screenshot from Google Article While this may seem like a minor issue, it can have significant implications for your application. When performing duplicate account checks, simply relying on a unique index in your database is insufficient. To safeguard your application, ensure that you normalise email addresses by removing dots in the local part before conducting duplicate checks. This small adjustment can prevent exploitation and maintain the integrity of your user database. Disclosure:  This entry is based on a collection of my personal notes, and some of the information may be outdated or no longer relevant. If you notice any inacc...

When implementing email validation, many of us focus solely on the structure of the email (Regex, anyone?). However, understanding the character limit specifications is equally important and often overlooked. RFC 3696 states "That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters." Source:  RFC 3696 In simpler terms: [local portion]@[domain portion] (i.e. john@website.com)   The local portion before "@":  64 characters "@" itself: 1 character The domain portion after "@":  255 characters   The total length cannot exceed 320 characters (64 + 1 + 255) Understanding these character limits is crucial when validating email addresses, as exceeding them can cause issues with email delivery and may compromise the security of your application. Disclosure:  This entry is based on a c...