Security is at the forefront of Hotjar’s development mindset. We’ve built both internal and external security checkpoints into the Hotjar application’s development pipeline.
Hotjar Coding Guidelines
Hotjar always sets our north star to deliver value to customers with small iterative updates that deliver impactful and meaningful changes. Our coding guidelines provide our engineers with the ability to be bold with changes while maintaining focus and understanding for security considerations.
Hotjar’s change control process is how we maintain our security focus. To do this, we implement some core guidelines for coding, which include:
- Atomic changesets. We commit when the task is finished.
- Commenting on methodology. Having a comment saying "increase i by 1" is at best useless, at worst old and incorrect. We always document intent - why we're doing this.
- Keep functions short. Each function should do one thing and one thing only.
- Keep things private. Encapsulation is a great thing. Expose a module interface as small as possible to the public.
- Hotjar’s Change Management process guides development through several checkpoints in which changes are committed from development to production environments.
- A change is initiated once the story enters a sprint.
- A comprehensive suite of automated tests is run by our Continuous Integration system against any revision that is a release candidate.
Code review is done by a different developer from the one who implements the change. They are usually from the same team unless relevant expertise from a different team is required. When larger changes are involved we often involve more than one reviewer. If all tests pass and the reviewer is happy with the pull request, they can approve it. This permits the pull request to be merged into our main branch later on.
- A developer queues to deploy their change. Our build system maintains who can deploy to each environment at what time to ensure deployments are handled consistently.
- Each separate service is first deployed to a staging environment where final manual verification can take place.
- Once the verification is done in the staging environment Hotjar continues to deploy to the production environment. If everything looks as expected with no alerts we then merge the pull request into the main branch and close the story.
Hotjar engages with industry-leading consultancies to perform third-party security assessments and penetration testing. The goal of these assessments is to validate Hotjar’s own security methods with an ‘outside’ perspective.
- Assessments are performed at least annually
- The results are communicated to all team members, with remediation efforts monitored in line with the criticality of issues discovered.
- Hotjar latest security assessment was performed: 31st October 2019
- The latest security assessment certificate can be found here
Bug Bounty Program
No technology is perfect, and Hotjar believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. Hotjar encourages responsible disclosure through the HackerOne program.
Our program provides us with the ability to continually monitor and review our application, and where necessary identify and remediate risks.
If you believe you've found a security issue in our product, we recommend you email firstname.lastname@example.org requesting an invite to the program.