GitHub – google/go-safeweb: Secure-by-default HTTP servers in Go.

DISCLAIMER: This is not an officially supported Google product.

go-safeweb is a collection of libraries for writing secure-by-default HTTP
servers in Go.

This project is in an early stage. We are currently not accepting any
contributions.

The flexibility of Go’s net/http package
allows users to quickly implement HTTP servers.

Responses are then written simply as slices of bytes, headers can be arbitrarily
manipulated and so on. This approach offers much needed flexibility for these
who really need it.

Unfortunately, this approach leaves great space for introducing security
vulnerabilities and even experienced developers tend to do so.

This document aims to design an HTTP API that eliminates whole classes of bugs,
like Cross-Site Scripting (XSS) or Cross-Site Request Forgery (XSRF). This can
be achieved by an approach known at Google as safe coding. Learn more at
Securing the Tangled Web (Chistoph Kern, 2014)
or
Preventing Security Bugs through Software Design (Christoph Kern, 2016).

Security mechanisms are applied by default (opt-out, not opt-in).

All opt-outs from security mechanisms are explicit. Wherever possible, they’re
contained inside a package or an option that’s easy to restrict.

Enforcing new security measures is feasible through AST manipulation. Existing
users can be migrated using static analysis and/or runtime monitoring. Read more
here.

Whenever possible, keep existing layouts, function signatures and other API
parts the same as the Go’s standard library. High compatibility enables wide
adoption.

Creating safe APIs for all the corner cases might result in a bloated codebase.
Our experience shows that this isn’t necessary.

Existing open-source frameworks or the Go standard library need to support each
developer scenario. This would have left us with limited options of creating
safe-by-default HTTP servers.

Go Safe Web aims to help you create a secure-by-default Go HTTP server and
nothing more. Features that are not security critical will not be added.
Focusing solely on security allows us to maintain high compatibility with the
standard library and makes adoption easier.

On a high level, we plan to address, or provide the needed infrastructure to
address, following issues (not an exhaustive list):

• XSS (cross-site scripting) and XSSI (cross-site script inclusion) – e.g.
  by controlling how responses are generated
• XSRF (cross-site request forgery) – e.g. by using Fetch Metadata policies,
  supporting token-based XSRF protection
• CORS (cross-origin resource sharing) – e.g. by taking control of CORS
  response headers and handling CORS preflight requests
• CSP (content security policy) –
  e.g. by automatically adding script nonces to HTML responses, adding relevant
  security headers
• Transport Security – e.g. by
  enforcing HSTS support
• IFraming – e.g. by setting relevant HTTP headers to restrict framing or
  providing server-side support for origin selection
• Auth (access control) – e.g. by providing infrastructure for plugging in
  access control logic in an uniform, auditable way
• HTTP Request Parsing Bugs – e.g. by implementing strict and well
  documented parsing behavior
• Error responses – e.g. by providing infrastructure for uniform error
  handling (e.g. to prevent accidental leaks or XSS from error responses)
• Enforcement of other security specific HTTP headers –
  here

Imagine an API for configuring access control. It features three types of rules:

• ALLOW(user) – allows a given user
• DENY(user) – denies a given user (has priority over ALLOW)
• REPORT(user) – reports that it has seen a request from a given user

Imagine now that at some point, security standards need to be increased and
user = "frombulator" has been determined to not meet the desired bar.

How do we, for all the services running in our company, address this?

1. For existing services, we add a LegacyFrombulatorAccess option like so:
   security.AccessControl(rules, unsafe.LegacyFrombulatorAccess()).
2. We change the security.AccessControl() call to add by default a
   DENY("frombulator") rule. This rule is not added if
   unsafe.LegacyFrombulatorAccess is applied.
3. Instead, unsafe.LegacyFrombulatorAccess adds a REPORT("frombulator")
   rule.

This way, we have:

• Ensured that all new callers of security.AccessControl use the safe setting
  by default.
• Can monitor existing services dependence on calls from the frombulator.
  After a period of observation (let’s say, 30 days):
  • If the service doesn’t receive requests from the frombulator: prune the
    unsafe.LegacyFrombulatorAccess option.
  • If the service does receive requests from the frombulator: inform the
    service owners and plan a fix.

Crucially, only the last case (dependence on unsafe configuration) requires
engineering work per service. The rest can be automated.

This approach is possible due to careful API design. A missing DENY or
REPORT rule, or a single sink in the form of security.AccessControl would
make this infeasible.

Every file containing source code must include copyright and license
information. This includes any JS/CSS files that you might be serving out to
browsers. (This is to help well-intentioned people avoid accidental copying that
doesn’t comply with the license.)

Apache header:

Copyright 2020 Google LLC

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.