Due to the integration with popular versioning tools, code reviews had become very popular. They are absolutely a MUST and should integrate with a team’s existing processes. It not only improves your code quality and helps escape major defects but it also helps developers be more familiar with all aspects of the application. Here is the list of DO’s and DONT’s in the code reviewing process:

DOs	DONTs
Have at least two reviewers	Do not leave the destiny of the code to just one person. In case that person misses something there is a good chance another person will catch it
Take your time to do a code review (and of course be aware that the team is waiting for you to finish it)	Do not rush, finding security and functional bugs is important and your team is relying on you to catch those
Make sure that code follows the right design and architectural standards	Do not be afraid or lazy to mention that the code is designed poorly and not according to standards. This is where the mess begins!
Make sure you express yourself clearly and correctly when communicating	Do not use slang or abbreviations, some people will not be able to understand it
Try to judge the code from the point of view of non-functional requirements. It is better to have a check list of things to check	Do not think that it is not your responsibility to think about other aspects of the code, except functionality
If you are new to the team and do not have the domain knowledge about the code, you should ask someone to help you review/explain the code	Make a thorough review every time you review the code. Do not mark it as approved if you do not fully understand it
Do long design reviews in person, so your team members can ask questions and get clarifications right away in the same interaction	Commenting a huge piece of code can be messy and inefficient
Do your own code review as well	Do not waste other people’s time. By reviewing your code yourself you can get rid of half the defects on your own
Keep your comments short and to the point	Do not start writing an article about a better approach that you had done a year ago while cruising over the Atlantic Ocean
Try to take breaks between reviewing code	Do not review code for too long in one sitting. You can lose your concentration and miss defects
Imagine how the code will work in production. Consider key user workflows and how that code will facilitate/block them	Do not just blindly click Approve button; think wider
Pay as much attention to the follow up review as to the original one	Do not think that all your comments will be addressed. Make sure to check fixes thoroughly

No one can write perfect bug-free code. Issues may slip past you and introduce broken functionality, performance degradation, security bridges, etc. That is why code reviews are crucial and in the end, four eyes are always better than two.

1. Have proper artifacts (code ,UML diagrams, test cases, design documents, requirements, wiki’s)
2. Collaboration, Peer review. Code should not go to production without being reviewed by your colleagues. Once you commit something send it to other dev to review
3. Trigger unit tests on each commit, run sanity test every hour and performance once a day
4. Constantly improving quality:
   • Bug parties: Have two people in separate rooms and give them to test one feature, and then compare results
   • Product owner should sign off on QA’s test cases, since they have better understanding of user’s workflows
   • Must have functional, integration and regression tests automated. These tests can also be shared with DEV team and depending on which part of the code was modified Devs can run respective test cases locally before committing
   • Parallelize your tests to execute them faster
5. Have design guidelines to speed up development work and stay consistent with each other
6. Automate as much as you can

1. Use Static Analysis Tools:
   • Sonar and Coverity - identifies critical security vulnerabilities. Easy to integrate, provides full code coverage and accurate results
   • Rose Checkers – enforces the CERT C/C++ Coding Standard
   • CERT Thread Safety Analysis - uses annotations to declare and enforce thread safety policies in C and C++ programs
   • AIR integer model – it’s an automated mechanism for eliminating integer overflow and truncation
   • Compiler-Enforced Buffer Overflow Elimination - prevents buffer overflows from succeeding in multithreaded code
2. Use Dynamic Analysis Tools:
   • Address Sanitizer – prevents buffer overflow and memory leaks
   • Tread Sanitizer – detects data races
   • Memory Sanitizer – detects uninitialized memory
   • Undefined Behavior Sanitizer – detects undefined behavior
3. Do Fuzz Testing using:
   • OSS-Fuzz – continuous fuzzing from Google
   • libFuzzer – coverage-guided fuzzing
   • American Fuzzy Lop – employs genetic algorithms to create test cases
4. Do Penetration Testing using:
   • Metasploit - is a framework with a large programmer fan base that adds custom modules, test tools that test for weaknesses in operating systems and applications
   • Nmap – used for discovering hosts and services
   • Wireshark – used for network troubleshooting and analysis
   • John the Ripper – used for cracking passwords
   • Burp Suite – It maps and analyzes web applications, finding and exploiting vulnerabilities
   • Nessus - checks computers and firewalls for open ports and for installations of potentially vulnerable software
5. Write security wrappers for the third-party libraries to protect your code
6. Do not release your code to production without confirming what impact has a particular vulnerability on the system
7. Log security-related events and monitor them. Sanitize what you put in your logs to avoid noise and missing important information. It is preferred not to log sensitive data, but if you have to, make sure it is encrypted
8. Stay up to date with OWASP updates and make sure you address their top 10 most critical vulnerabilities

JWT is used for creating access tokens and passing claims between two parties. You should use it whenever you want to pass information from the server to the client in a secure manner. However, JWT is not 100% secure. Everyone still can see the information which is available as part of the token. JWT should be cryptographically signed to ensure that token has not been tampered with (JWS -RFC7515). It can be encrypted to keep sensitive information hidden from the client or third parties (JWE - RFC7516). Or it can be both signed and encrypted.

JWT is mainly used in web applications. JWT can be used to authorize users to services. An authenticated user may receive a JWT that can be passed to downstream services to both identify that user and provide that user’s authorization credentials.

You can user any kind of technology in order to work with JWT: JavaScript, Node.js, Java, .NET, Python, Ruby, PHP, etc. It can be passed as part of URL, form body parameter, cookie or HTTP Header. Mainly JWT is used for single sign-on (SSO) context, for example if you have multiple websites and you would like to use the same token across all of them, you can have authentication to be made against one website and use the same token against other websites.

JWT contains three parts (all are base64 encoded), which are separated with dots:

1. Header
2. Payload
3. Signature

Header is a JSON object which usually contains two parts:

• “typ”: JWT
• “alg”: hashing algorithm (HS256, RS512, ES384, etc.) You can provide any hashing algorithm you like.

Payload –contains all the necessary data which needs to be sent from the server to the client or vice versa. Information is JSON representation of claims (“key”:”value”). Default keys include the following:

• “iss”-issuer
• “sub”-subject
• “aud”-audience
• “exp”-expiration time
• “nbf”-not before
• “iat”-issued at
• “jti”- JWT id

You are not limited to these keys and you add your own custom keys.

Remember! All information in payload is not encrypted and visible to everyone; however client or other third parties cannot modify any information in payload since it will invalidate the entire token.

Signature is a hash of header and payload using a secret. Looks like this and it’s very hard to decrypt in general:

var t = base64Encode(header) + “ . ” + base64Encode(payload);
var signature = base64Encode(t, secret);

More info about JWT can be found here: IETF Trust