OWASP Go Secure Coding Practices — Index

A human-readable index of the OWASP Go Secure Coding Practices Guide, a comprehensive security guide for Go web application developers based on the OWASP Secure Coding Practices Quick Reference Guide.

Generated from OWASP/Go-SCP at commit e6c9235.

14 chapters · 33 sections · 57 Go code examples

• Input Validation (3 sections)
• Output Encoding (3 sections)
• Authentication and Password Management (5 sections)
• Session Management
• Access Control
• Cryptographic Practices (2 sections)
• Error Handling and Logging (3 sections)
• Data Protection
• Communication Security (3 sections)
• System Configuration
• Database Security (5 sections)
• File Management
• Memory Management
• General Coding Practices (3 sections)

In web application security, user input and its associated data are a security risk if left unchecked. We address this risk by using "Input Validation" and "Input Sanitization".

• Input Validation
• Validation — In validation checks, the user input is checked against a set of conditions in order to guarantee that the user is indeed entering the expected data.
• Sanitization — Sanitization refers to the process of removing or replacing submitted data. When dealing with data, after the proper validation checks have been made, sanitization is an additional step that is usuall... (1 code examples)

Although output encoding only has six bullets in the section on OWASP SCP Quick Reference Guide, undesirable practices of Output Encoding are rather prevalent in Web Application development, thus lead...

• Output Encoding
• XSS - Cross-Site Scripting — Although most developers have heard about it, most have never tried to exploit a Web Application using XSS. (3 code examples)
• SQL Injection — Another common injection that's due to the lack of proper output encoding is SQL Injection. This is mostly due to an old bad practice: string concatenation. (2 code examples)

OWASP Secure Coding Practices is a valuable document for programmers to help them to validate if all best practices were followed during project implementation.

• Authentication and Password Management
• Communicating authentication data — In this section, "communication" is used in a broader sense, encompassing User Experience (UX) and client-server communication.
• Validation and Storage — The key subject of this section is the "authentication data storage", since more often than desirable, user account databases are leaked on the Internet. Of course, this is not guaranteed to happen. (3 code examples)
• Password policies — Passwords are a historical asset, part of most authentication systems, and are the number one target of attackers.
• Other guidelines — Authentication is a critical part of any system, therefore you should always employ correct and safe practices. Below are some guidelines to make your authentication system more resilient:

In this section we will cover the most important aspects of session management according to OWASP's Secure Coding Practices.

• Session Management — 5 code examples

When dealing with access controls the first step to take is to use only trusted system objects for access authorization decisions.

• Access Control — 1 code examples

Let's make the first statement as strong as your cryptography should be: hashing and encrypting are two different things.

• Cryptographic Practices — 2 code examples
• Pseudo-Random Generators — In OWASP Secure Coding Practices you'll find what seems to be a really complex guideline: "_All random numbers, random file names, random GUIDs, and random strings should be generated using the crypto... (2 code examples)

Error handling and logging are essential parts of application and infrastructure protection.

• Error Handling and Logging
• Error Handling — In Go, there is a built-in error type. The different values of error type indicate an abnormal state. Usually in Go, if the error value is not nil then an error has occurred. (5 code examples)
• Logging — Logging should always be handled by the application and should not rely on a server configuration. (2 code examples)

Nowadays, one of the most important things in security in general is data protection. You don't want something like:

• Data Protection — 4 code examples

When approaching communication security, developers should be certain that the channels used for communication are secure.

• Communication Security
• HTTP/TLS — TLS/SSL is a cryptographic protocol that allows encryption over otherwise insecure communication channels. (8 code examples)
• WebSockets — WebSocket is a new browser capability developed for HTML 5, which enables fully interactive applications. (1 code examples)

Keeping things updated is imperative in security. With that in mind, developers should keep Go updated to the latest version, as well as external packages and frameworks used by the web application.

• System Configuration — 6 code examples

This section on OWASP SCP will cover all of the database security issues and actions developers and DBAs need to take when using databases in their web applications.

• Database Security
• Connections — sql.Open does not return a database connection but *DB: a database connection pool. When a database operation is about to run (e.g. (3 code examples)
• Authentication — If your Go web application only needs to read data and doesn't need to write information, create a database user whose permissions are read-only.
• Parameterized Queries — Prepared Statements (with Parameterized Queries) are the best and most secure way to protect against SQL Injections. (1 code examples)
• Stored Procedures — Developers can use Stored Procedures to create specific views on queries to prevent sensitive information from being archived, rather than using normal queries.

The first precaution to take when handling files is to make sure the users are not allowed to directly supply data to any dynamic functions.

• File Management — 2 code examples

There are several important aspects to consider regarding memory management. Following the OWASP guidelines, the first step we must take to protect our application pertains to the user input/output.

• Memory Management — 3 code examples

• Cross-Site Request Forgery — By OWASP's definition "Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.". (source) (1 code examples)
• Regular Expressions — Regular Expressions are a powerful tool that's widely used to perform searches and validations. In the context of a web applications they are commonly used to perform input validation (e.g. (2 code examples)

Generated by go-scp-index from OWASP/Go-SCP.