Some notes to make the Go website more secure

Tram Ho

In the previous sections, we have built a relatively complete Backend application (CRUD, with unit tests) with Go. The next factor that concerns us is the security of the system. In this article, we will learn the basic notes that help the website to be completely safe, avoid some security risks, along with the introduction of tools and libraries to make the system more secure than before. dangerous holes.

1. Input Validation and Output Encoding

Do not believe what the user enters.

Leading critical vulnerabilities such as XSS or SQL Injection all stem from negligence in checking input data. Therefore, the inspection of input data carefully will minimize.

Failure to check input data can lead to Injection errors (Top 1 according to OWASP list).

Here are some tips to help minimize the risk of user data coming from the OWASP organization

  • Perform data validation on a reliable system (eg Server)
  • Identify all data sources and classify them as reliable and unreliable. Validate all data from untrusted sources (e.g. Database, file stream, etc.)
  • Use appropriate characters sets , such as UTF-8, for all input.
  • All invalid input will be rejected.
  • Validate, check all data from client provided before processing, including all params , URLs and HTTP headers .
  • Make sure that only HTTP request and HTTP response headers contain ASCII characters.
  • Check the data type of input data.
  • Check the input data length.
  • Check for dangerous characters like: <> “‘% () & + ‘”
  • Check out the characters
    • Null bytes (% 00)
    • Newline (% 0d,% 0a, r, n)
    • Directory path (../ hay ..)


Go supports many packages from GoTeam as well as 3rd parties to help check input data.

  • strconv converts the data type.
  • The string contains the string format function.
  • utf8 performs functions of encode, decode, format characters under utf8 standard.
  • Decode form and Encode url value
  • validator : Validate data structures and fields, such as Cross Field, Cross Struct, Map, Slice or Array.
  • Filter, encode special characters, dangerous can use the following 3rd party packages. Note the default html package included in Go also supports filtering, encode special characters, but only apply with 5 characters <,>, &, ‘and “ , which is not really safe enough.

XSS example

  • Server listen at port 8080
  • Route ‘/’ takes query param1 and response returns the status of query param1

=> No validate data passed

Try sending a normal message, hello world for example. The screen will display the content param1 has just passed.

Tried with an HTML snippet, because the server did not validate, it left characters like <> / ‘”

Play a script test, his name 😆

How to fix

Use the libraries suggested above to check and filter the query param1

SQL Injection example

We have the following code:

The code takes param id from the user and uses the string addition method to execute the SQL Select database statement.

Because the param id is not checked, we will exploit it by passing an id of 1 OR 1=1

=> The executed SQL statement will be

All data in the creditcards table will be returned instead of 1 record with customerId = 1

How to fix

Do not use the sequence of SQL statements to call the database, use Prepare Statements . Prepare Statements will check the parameters before executing on the database, making the application more secure.

The syntax for using Prepare Statements is different for different database management systems.

2. Authentication and Password managerment

Below are the OWASP recommendations to help make the system more secure when authenticating and managing passwords.

  • Require authentication with all pages and resources, except for public ones.
  • The authentication must be performed on a reliable system (eg server).
  • Centralized deployment of authentication on the system, including external services .
  • Use one-way functions to encrypt passwords, Do not use weak hash functions such as MD5 or SHA-1. OWASP recommends using hash functions such as bcrypt , pbkdf2 , argon2 or scrypt .
  • Validation is complete when all input has been verified, especially for the implementation of sequential authentication.
  • Validation error response does not indicate which part of the authentication data is incorrect. For example, instead of “Invalid username” or “Invalid password,” return “Invalid username and / or password” for both.
  • Use authentication with external connections (such as API calls).
  • Only use HTTP POST to submit information that needs authentication.
  • Re-authenticate users before performing important actions

3. Session Management

  • Session creation must always be done on a trusted system (eg Server).
  • Session management should use algorithms good enough to ensure the session identifier is random.
  • Logout the user when the session expires or is deleted.
  • If a session is established before logging in, close the session and set up a new session after successful login.
  • Simultaneous login with the same user ID is not allowed.
  • Encrypt the data transmission environment between client and server with TSL
  • Set the “secure” field for cookies.
  • Set the HttpOnly field in the cookie.

Set httpOnly

HTTPS server

4. Some other notes

File Management

For file upload forms, the system should limit the file extension to be uploaded to the server (white list) to prevent hackers from uploading malicious files to the server.

For example when uploading photos

Cross-Site Request Forgery

Cross Site Request Forgery (CSRF) is a technique that attacks by using a user’s authentication authority on a website. CSRF attacks users, from which hackers can perform operations that require authentication. In a nutshell, this is an attack technique based on unauthorized borrowing.

For example

The website uses HTTP GET , to change the account recovery email address

  1. Victims log into the site
  2. The hacker sends the following link to the user: [email protected]
  3. If the user clicks the link above, the account recovery email address will be changed to the hacker email.

Changing from HTTP GET to HTTP POST (or any other method) will not solve the problem. Using cookie secret, rewriting the URL or HTTPS will not solve it thoroughly.


Generate a token corresponding to each form, this token will be unique for each form and usually the function that generates this token will take the argument “SESSION” or be saved in SESSION. When receiving HTTP POST command, the system will perform matching token value to decide whether to execute or not

On the server we will use the Gorilla CSRF package.


The above only includes basic notes to help prevent and minimize the risk of website before attacks. However, there is no guarantee that our system is completely immune to attacks (1-meter-high Taoist, 1-meter-high Macao), there are still undiscovered holes, lines The code is full of bugs or even bugs in hardware that can’t be fixed on day 1 and 2 with software patches.


Share the news now

Source : Viblo