Pushing Left, Like a Boss — Part 5.3 — Browser and Client-Side Hardening

Disabling ‘Remember Me’ Features

Do Not Allow Caching of Sensitive Data

HTTPS Everywhere

I feel strongly about client-side hardening. — http://sector.ca/

Use Every Possible Security Header

Content-Security-Policy: default-src ‘self’; block-all-mixed-content;
Referrer-Policy: strict-origin-when-cross-origin
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Permitted-Cross-Domain-Policies: none
Access-Control-Allow-Origin: https://site-that-you-trust.com
Expect-CT: max-age=86400, enforce, report-uri=”https://myserver/report"
Feature-Policy: camera ‘none’; microphone ‘none’; speaker ‘self’; vibrate ‘none’; geolocation ‘none’; accelerometer ‘none’; ambient-light-sensor ‘none’; autoplay ‘none’; encrypted-media ‘none’; gyroscope ‘none’; magnetometer ‘none’; midi ‘none’; payment ‘none’; picture-in-picture ‘none’; usb ‘none’; vr ‘none’; fullscreen *;
<httpRuntime enableVersionHeader=”false” />

A special note on the X-XSS-Protection header: This header is now considered legacy/deprecated. It has vulnerabilities within the header implementation itself. It is only used for backward compatibility, and unfortunately as of 2019 it is being attacked in older browsers. It is no longer advisable that we use this security header.

Pushing Left, Like a Boss — Part 5.2- Use Safe Dependencies


Automating this should be part of every CD/CI pipeline. You should also automate scanning of your source code repository on a regular basis. Everyone should do this, for every project, no matter how small. It’s so easy, and it’s such a huge win for the security of your applications, there is no excuse not to do it.


** The CVE list of vulnerabilities is not exhaustive. Many nation-states (including the one you live in), as well as criminal, terrorist, hacktivist, and other malicious groups, actors or organizations do not report zero days that they find(vulnerabilities that are not known to the public and for which there is no known patch), in order to keep them for use as part of their own nefarious activities. Just because you have scanned your third party components for vulnerabilities does not mean they are bulletproof. Sorry folks.

Photo: #WOCTechChat

Pushing Left, Like a Boss — Part 5.1 — Input Validation, Output Encoding and Parameterized Queries

Image Credit: #WOCTechChat

Input Validation

Image Credit: #WOCTechChat

Output Encoding

Image Credit: #WOCTechChat

Parameterized Queries

Pushing Left, Like a Boss: Part 4 — Secure Coding

In the previous article in this series we discussed secure design concepts such as least privilege, reducing attack surface, failing safe and defense in depth (layered protection). In this article, we are going to talk about secure coding principles which could be used to help guide developers when implementing security controls within the software they create.

Coding Phase of the SDLC 

What is “secure coding”?

The one thing that you should always remember when coding defensively, is that you need to assume that users will do things that you did not plan. Strange things that you would have never dreamed of. Trust me.

Why is it ‘secure coding’ important?

I’m not going to answer that. If you are reading this blog, you already understand why secure coding is important. I think the real question here is: “How do I explain how important it is to developers? To project managers? To executives? How do I get them to give me time in the project for it?” I’m asked this quite often, so let me give you a few options.

  1. You can explain using statistics and numbers, to predict the financial implications of a major security incident or breach. You can provide a cost/benefit analysis of how much less an AppSec program would cost, how your business would receive a good return on investment (ROI). I used this approach and was approved to launch my very first AppSec program.
  2. You can explain the business implications of a major incident, the loss of reputation, financial loss or legal implications that would result from a major incident or data breach. I tend to use this when trying to justify large changes such as creating a disaster recovery plan/site, or an AppSec advocacy program, or giving developers security tools (that tends to scare the pants off of most management types).
  3. You can create a proof of concept to explain a current vulnerability you have in your product, to show them directly the consequences that can occur. This might lose you some friends, but it will certainly get your point across.
  4. You can sit down with whoever is blocking you and have a real discussion about why you are worried about your current security posture. Explain it to them like they are a highly intelligent person, who happens to not know much about security (which means respectfully, and with enough detail that they understand the gravity of the situation.) It is at this point that I would tell them that I need them to sign off on the risk if we do not correct the problem, and that I can no longer be responsible for this. It is at this point that either 1) I get what I want or 2) I know this is no longer my responsibility.

If I get to step 4, I start to look for a new job.


Why are users the absolute worst?

Broken security control – Photo credit