|Damian Bogel e4f95d07b2||3 days ago|
|.github||2 months ago|
|cmd/bancheck||4 weeks ago|
|docs||8 months ago|
|examples||2 days ago|
|internal/requesttesting||1 month ago|
|safehttp||2 days ago|
|safesql||6 months ago|
|tests/integration||2 days ago|
|LICENSE||1 year ago|
|README.md||6 months ago|
|go.mod||1 month ago|
|go.sum||4 days ago|
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
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):
Imagine an API for configuring access control. It features three types of rules:
ALLOW(user)- allows a given
DENY(user)- denies a given
user(has priority over
REPORT(user)- reports that it has seen a request from a given
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?
LegacyFrombulatorAccessoption like so:
security.AccessControl()call to add by default a
DENY("frombulator")rule. This rule is not added if
This way, we have:
security.AccessControluse the safe setting by default.
frombulator. After a period of observation (let’s say, 30 days):
frombulator: prune 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
REPORT rule, or a single sink in the form of
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.)
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.