shieldfy / api-security-checklist Goto Github PK
View Code? Open in Web Editor NEWChecklist of the most important security countermeasures when designing, testing, and releasing your API
License: MIT License
Checklist of the most important security countermeasures when designing, testing, and releasing your API
License: MIT License
Hello,
It seems that this repository was made only for RESTful APIs. Maybe it would be nice to add a section for GraphQL, which is a nice alternative to REST.
What do you think?
We now have two Japanese translations for the checklist, README-ja.md
and README-jp.md
(just one should be enough, I think).
In terms of the language codes used, README-ja.md
is more accurate (jp
is the correct country code for Japan, but ja
is the correct language code for the Japanese language). However, in terms of the actual translated content, I don't know which of the two would be better, seeing as my understanding of Japanese is very limited.
Perhaps someone who is good with the Japanese language could take a look at the two and send a PR to merge them (from the two files, copy whichever translations are the best, into one single file; delete the remainder)?
Maybe this is something that @arinco or @iogi could take a look at?
Cheers. ๐
I want to translate this repo to korean. How do I do this? Would I send a PR for korean README to you?
Thanks :)
I understand this recommendation:
Make token expiration (TTL, RTTL) as short as possible.
Though I wonder what qualifies "as short as possible". If a json web token is used as a session, making that session expire after five minutes is going to make a horrible user experience.
Is there a recommended strategy for short expiration with longer sessions?
Link to pull request with your CodeQL query:
Relevant PR: github/codeql#7286
List the CVE ID(s) associated with this vulnerability. GitHub will automatically link CVE IDs to the GitHub Advisory Database.
Describe the vulnerability. Provide any information you think will help GitHub assess the impact your query has on the open source community.
Directly incorporating user input into HTTP requests dispatched from the Java EE RequestDispatcher without proper validation of the input can allow any web application resource such as configuration files and source code to be disclosed.
As stated in the Java API doc, when using a Java EE RequestDispatcher, requests may be dispatched to any part of the web application bypassing both implicit (no direct access to WEB-INF or META-INF) and explicit (defined by the web application) security constraints. Unsanitized user provided data must not be used to construct the path passed to the RequestDispatcher as it is very likely to create a security vulnerability in the application.
This query detects unsafe invocations of RequestDispatcher with user controlled input. Important features include:
java.nio.file.Path
packageProvide at least one useful result found by your query, on some revision of a real project.
Originally posted by @luchua-bc in github/securitylab#495
So, for the topic, which standards for Authentication, token generating, password storing can be used? Can offer some sample implement projects?
It reads,
Don't extract the algorithm from the payload. Force the algorithm in the backend (HS256 or RS256).
Normally, we can find "alg" in the header part, not the payload part of JWT.
Well, what is your point of the risk case?
If an application are using JWT in browsers it should be stored securely in a cookie which requires:
Hello,
Why is it required to have security headers alike HSTS, CSP and X-FRAME OPTIONS if the API is not browsable?
no word about request integrity
a strategy to prevent replay attack ?!?
Each thing in the list deserves a file on the rationale behind it, even if those are largely URLs.
Hi,
I agree with most rules but I don't understand:
User own resource id should be avoided. Use /me/orders instead of /user/654321/orders
From my perspective. I would prefer use /user/654321/orders
than /me/orders
. For the latter, at the end, I need to do the lookup in all cases. So I prefer a non ambiguitous uri than "/me/orders". Even if more readable from a human point of view, at a technical one, it can lead to confusion.
So shouldn't it be more
User own resource id should be avoided. Avoid using /me/orders. Better/explicitely use /user/654321/orders instead.
Thanks for the list, will be useful !
The HTTP method PATCH might not be in the standard yet, but it's widely used. It would be good to mention it, as it makes partial updates "possible".
Reference: https://tools.ietf.org/html/rfc5789
This will let translation file easily to spot if it is outdated.
I suggest using this format for version control (V.MAJOR.MINOR.REVISION)
MAJOR = new standard / concept
MINOR = add more checklist
REVISION = correct some typo
for example,
Base file(V1.1.2)
Translation file1(V1.1.1) (Outdated by 0.0.1 version but can be ignored)
Translation file2(V1.1.2) (up to date)
Translation file3(V1.0.1) (Outdated)
Info about version might include in their respective files (let translators handle by themselves), base file or centralize file.
You might as well consider about the changelog. (not necessary though)
Is that possible can someone explain why the "User own resource ID should be avoided. Use /me/orders instead of /user/654321/orders." is a security concern?
I agree that user can know your 654321 is your user id then probably loop to try /user/654322/orders etc. However, isn't it the api should check whether the user id has privilege as well? E.g. is 654322 customer of the caller's token user? If yes, he can still view it.
So using pk here is just making it easy to loop and test, but by right the code itself should have checking for privilege too.
If not, using UUID would be insecure too right? I can still loop it, but longer period. And if somehow i know other company customer uuid, I can access it too.
Is there any other point I miss out? Thanks!
Are Serbian translations needed? If so, I'm open to contribute ๐
Gjjg
don't use JWT. JWT terrifies me, and it terrifies all the crypto engineers I know. As a security standard, it is a series of own-goals foreseeable even 10 years ago based on the history of crypto standard vulnerabilities. Almost every application I've seen that uses JWT would be better off with simple bearer tokens.
Also, link to a longer comment from him about why JWT is a bad plan.
Source: Languages used on the Internet -> Content languages for websites (2017.07.16).
Note: Source does not distinguish between dialect variants, regional L10N, etc (for example, with Chinese, I would assume that the statistics includes both simplified and traditional writing variants, or with Portuguese, including both Portugal and Brazil variants alike).
For the purpose of this issue, I'm only listing the top 10 languages mentioned by the source page (there are 38 mentioned by the source list in total, plus a secondary list on the source page; because this issue is only intended to float some general ideas and doesn't concern any concrete goals or plans, being excessive isn't necessary).
Rank | Language | Percentage | Translation Coverage |
---|---|---|---|
1 | English | 51.6% | Original document language. |
2 | Russian | 6.6% | Completed (thanks @tsybenko). |
3 | Japanese | 5.6% | |
4 | German | 5.6% | |
5 | Spanish | 5.1% | |
6 | French | 4.1% | Completed (thanks @flibustier and @Sinequanonh). |
7 | Portuguese | 2.6% | Completed (thanks @marcossffilho). |
8 | Italian | 2.3% | |
9 | Chinese | 2.0% | Completed (thanks @GrayLand119 and @j-gao). |
10 | Polish | 1.7% |
The purpose of this issue is to suggest possible targets for future language translations, for anyone that might be interested in introducing new translations to the repository. This repository (at this time, currently) is being watched by 205 GitHub users and has 422 forks, and so, maybe this might be useful for someone looking for possible target languages. The logic/rationale here is to hopefully encourage translation of the repository to those languages perceived as being most widely used on the internet (and thus, within the realm of the relevant scope of this repository). Using alternative sources may yield very different results.
Based on the above-mentioned information, these could be good possible target languages for translation at this time:
Also worth mentioning that because this repository is very young and is still a living document, the possibility of data between translations becoming out-of-sync is quite high. There should be no urgency here.
See: https://github.com/blog/1184-contributing-guidelines
Due to that this repository is currently trending very successfully, the number and frequency of pull requests to the repository, issues created, discussions, etc, I think adding some formal procedures or guidelines to the repository might be a good idea, to avoid possible future problems, unwanted pull requests (so far, all pull requests look pretty good, but there has been 17 of them already, and the repository is only 3 days old, and so, I think, there's a strong chance of merge conflicts, bad/unwanted pull requests and similar such things occurring at some point in the future). 16 issues created thus far in that 3 days, all legit/good, except for one, which looks a bit spammy (#19); Not sure if formal procedures or guidelines would help at all in that regard, but in any case, it couldn't hurt. Anyhow, figured it might be worth suggesting this. :-)
Don't use Basic Auth. Use standard authentication instead (e.g., JWT).
This is not very helpful. First of all, "Basic Auth" is "standard" in a way and broadly supported. I would recommend adding a bit more context:
Don't use Basic Auth as the end-user authentication measure. Use OpenID Connect or OAuth 2.0 flow. For server-to-server integrations (M2M), Basic Auth might still work but we recommend extending it with mTLS or VPN.
For example,
if your API security has been compromised, what will you do?
- Shutdown your system. (should be the last resort)
- Shutdown only vulnerable service.
- Revoke API Authorization from certain app/people.
Checklist of the most important security countermeasures when designing, testing, and releasing your API.
Since the scope include release phase then it should has topic/bullet that talk about backup plan.
Ways to handle backup plan might not be necessary but at least backup plan topic should be mention in the document somewhere because some backup plan might affect API design or even a whole system structure.
I have a project that our API should verify a parameter which is about the trade.
We use a method like the demo.
Demo
Request:
Host:192.168.0.1
parameters: sign - To verify the parameter
tradeinfo
sign = sha1(secretKey + tradeinfo + secretKey);
This might seriously cripple database performance since you are suggesting a data type ~68 bytes larger than an integer and which indexes are much more expensive to compute.
What is the motivation behind this rule?
What is the pros and cons for these two identity?
"sensetive" is spelled incorrectly
It looks like most of the advice from the OWASP REST Cheat Sheet is discussed in this API-Security-Checklist, but OWASP talks about the importance of CORS, which is not mentioned at all in this API-Security-Checklist. Probably good to make mention. Also, the OWASP REST Cheat Sheet provides a bit more guidance regarding validation that might be good to incorporate.
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md
In "README.md", "็ฐกไธญ็" means simplified chinese version, but "็ฐก" is a traditional chinese character, it should be "็ฎ".
If I leave DEBUG mode on, my api will generate tons of log
Hi, thx for ur exciting work! This checklist helped me very much.
But I noticed that this repo has had 9 issues & 9 pull requests(including mine) now, which still waiting for a reply.
So, let's make this repo be fashionable again. ๐
You should mention range, type and length checks. Peculiarities of JSON/XML parsing should also be mentioned as parser very often work outside of the "safe" realm on most script interpreters, without much failsafe logic. Node notably had an alarming amount of bugs when working with multi-byte encodings.
Websocket handling is another point where most API writers completely disregard such basics. Some try to implement a per byte socket handling, that will eagerly split multibyte chars into impossible bits that can later be used in different "escape" scenarios or be used to attach 3rd party libs.
how are we supposed to get the token to the authenticated user after authentication?
It's better to add Content-Disposition: attachment; filename="api.json"
to response header in the case that some browsers had the vulnerability of nosniff
bypass. But for keeping this guideline simple, maybe this shouldn't be added. How do you think?
This advice:
Is a bit misguided as they only really have relevance if HTML is returned. If the API returns JSON or raw text there is no way that they can be affected by XFO or CSP.
I can see an argument for XCTO in some circumstances (e.g. SOAP requests).
I'd also include Strict-Transport-Security in the list as that really should be issued by pretty much everything HTTP page.
This may sound pedantic but I hear it all the time and it leads to confusion about OAuth.
OAuth is not an authentication (AuthN) mechanism, it is an authorization mechanism (AuthZ) which relies on an authorization service or identity provider to confirm the identity of the principal. OIDC might be one mechanism to support this.
Please remove OAuth from the line in authentication section:
"Don't use Basic Auth. Use standard authentication instead (e.g., JWT, OAuth)."
Ok
http://blog.portswigger.net/2016/11/json-hijacking-for-modern-web.html
Also contains other helpful hints too
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.