Young hacker smiling

We hack your software

zero false positives

Expert intelligence + effective automation


The goal of Fluid Attacks blog is to share opinions and knowledge on information security issues in a clear and understandable manner.

We invite you to share your knowledge with us and the world.

The target audience is people who don’t have an advanced technical knowledge. You must use simple language but provide relevant knowledge on security issues.


The blog topics are oriented only towards security and IT, however, there are situations that are not necessarily security related but can be treated as such:

  1. How to explain to a Manager that they must invest in security.

  2. How to use a specific component: You can explain the secure way to use and implement it.

  3. Explain a concept by solving a hacking challenge.

You can also check our list of topics.

Reader’s profile

  • Age range: 20 – 60 years old.

  • Level of Education: Undergraduate (Higher Education).

  • Role: From students to CISO (Chief Information Security Officers).

  • Knowledge: Varied with emphasis on information security.

  • Interests: IT and information security.

Acceptance Criteria

1. Title

The title of the article must grab the reader’s attention. It must not exceed 35 characters

  1. Make the topic something fun or curious. It can be in the form of a question.


    • Wanting the Cookie.

    • Information Security, an expense or an investment?

  2. Avoid generic titles at all costs.


    • SQL Injection.

    • XSS Vulnerability.

  3. The title must reflect the content of the document, always avoid false expectations.

    Examples: Whitelist; your ally in input validation, and then talk about injections without touching the subject of whitelist or their implementation.

2. Structure

All documents must have:

  1. First section: An introduction that tells the reader what he/she can expect.

  2. Last Section: A short conclusion that tells the reader the overall topic.

  3. The document must have a LIX complexity below 50. This guarantees that the document is easy to read.

3. Format

Documents will only be accepted in an AsciiDoc format. For more information check out our format page, the AsciiDoc guide, or a quick reference.

4. Word limit

Documents have strict length limits:

  1. For KB documents: Between 400 and 800 words.

  2. For Posts: between 800 and 1600 words.

  3. For pages (sites): Between 400 and 1600 words.

5. Semantic Line Breaks

Documents must have Semantic Line Breaks (SLB), in order to facilitate editing and keep an organized record of modifications in our version control system (Gitlab). To do this, we define the following rules:

  1. Minimum words before a SLB: 4.

  2. Maximum number of characters before a SLB: 80.

  3. A SLB must be added after a period (.).

  4. A SLB can be added after linking words and connectors, depending on the context and respecting the previous rules.

Exceptions to the rule are:

  1. Links.

  2. Source Code.


Figure 1. Example SLB.

For more information regarding LSB and their use, You can checkout the semantic linefeeds guide, semantic line wrapping guide, or the AsciiDoc documentation

6. Images

  1. All documents must include at least one image related to the topic being presented.

  2. Images that are not yours must include a reference..

  3. Include a description for the image.

7. Videos

  1. They must be your own videos.

  2. The video must be sent in order to upload it to our Fluid Attacks youtube channel.

  3. They video must include an introduction and a conclusion.

8. Source

Unless the language forces you to do otherwise, the source code must comply with the following:

  1. Be in english (even the comments).

  2. Indent using 2 spaces instead of tabs, unless the language requires otherwise.

  3. Use the brace style seen in stroustrup (no one liners). Example.

  4. Lines must not exceed 80 characters in length.

  5. Lines must not contain debug comments left behind.

  6. Function definition must be separated by 1 empty line, unless the linter or the language requires otherwise.

Embedded code snippets must comply with the following:

  1. Be enumerated. To do so add the parameter linenums to the source block.

  2. Not have more than 8 lines.

  3. It is not allowed to repeat a snippet that has already been used in the guide.

  4. Add the lines of code to the post using a code block, don’t use images.


function cool(x) {
  /*Please use SHORT comments in english when necessary.
  You must explain your code in the document*/
  int y;
  y = x + 1;
  return y;
  //And remember, do NOT exceed 8 lines ;)

9. Exploit Explanations

In the case of documents focused on exploitation, once the procedure is explained, we recommend including a short gif showing the result of what was explained. Add a description for the gif.

Figure 2. Exploit description example.

10. Not permitted

  1. Code snippets that are not your own.

  2. Images without the original reference.

  3. Technical explanations not relevant to security:

    Example: Introduction to a programming language without mentioning how to securely program in said language.

11. Metadata

Metadata are variables that are included at the beginning of a document which influence the final rendering of it and how the search engine indexes them. You can find more information regarding AsciiDoc variables by clicking here.. Below is a table with the mandatory metadata for a document:

Table 1. List of metadata present in a document.










Link where the document can be found once it has been accepted. The slug must be the name of the article in lowercase, with no spaces, prepositions, conjunctions or connectors and separated by a dash "-".





Brief summary of the main idea of the document (250 to 300 characters long). This description will appear in the search engine search results.





Keywords through which a search engine can find the document. The document must include 6 keywords.





Attribute that indicates if a translated version of the documents is available in the Fluid Attacks website. In case there is a translated version available, The slug of the translated document must be included.





Short subtitle that specifically indicates the purpose of the document. It must not exceed 55 characters.





Unique metadata of Knowledge Base articles. The only accepted value is yes.





Date the document was created.





Category to which the document falls under. Example: Security opinions, Best practices, etc.





Similar to the metadata :keywords: Noteworthy words that index the document internally.





Image that will appear in the article preview. This image must have certain dimensions, 600 x 200 px and must not exceed 300 Kb in size.





Description of the image in the article preview.





Name of the author that will appear at the top of the document. Name and last name only.





Name and extension of the image that represents you as the author. The only extension permitted is PNG.





Name that will appear under the author’s image/picture. It can be your full name or nickname.





Main information about the author: scholarship, experience, role (if it applies).





Additional information about the author: likes, interests, links to personal blogs or profiles.

12. Additional Information

  1. If acronyms are used, their meaning should be included in parentheses.

  2. Include references when using fragments from external sources.

  3. Paragraphs must be original, don’t use text from other sites unless they are specific phrases.

  4. Foreign and reserved words used outside of blocks of code must use monospace.

  5. Make sure to include the link: before adding a link.

  6. When writing the company name (Fluid Attacks), consider the following cases:

    • Case 1: If the name is placed next to the company logo, it must be written as follows:

      | >>|> fluid
      |___|  attacks
    • Case 2: If the name is used as part of a domain, URL or file path, it must be written in lowercase without spaces:

    • Case 3: In any other case, it must be written in Title Case and separated:

      Fluid Attacks: We hack your software, zero false positives
  7. When including a reference, use the letter "r" as an anchor_ID followed by the reference number. Use superscript to quote it.


I'm talking about some topic
and now I need to cite a reference <<r# ,^[#]^>>

== References

. [[r#]] link:https://my-url[Fancy name for url].
  1. For more information regarding AsciiDoc, check out our allowed formats and examples.


If you want to share your security knowledge and opinions with the community and you are not part of Fluid Attacks, you can be a guest author, write your post in a text editor of your choosing and send us everything you need to publish it. Do not forget to send with it, a paragraph telling us a little bit about yourself and an image that represents you, since at the end of the post the guest’s profile will be included.

  1. Author’s name and last name.

  2. Short description, minimum 15 words – maximum 30. You may include: What you do for a living, years of experience, certifications, likes and interests.

  3. Optional: Link to personal blog – githublinkedin


  1. If you are part of the Fluid Attacks team, you can send us your document through a Merge Request in the AsciiDoc format and complying with all the above rules.

  2. If you are not part of the Fluid Attacks team, you just have to send your document to attaching all the required files in order to create the post. Once the document is sent, It is put through an evaluation process to determine if it will be published.

Terms and Conditions

  1. Fluid Attacks reserves the rights of admission of all documents sent in.

  2. We perform a non-substantive review of the document. Fluid Attacks doesn’t evaluate if we agree or not with the author’s opinion but only that the documents meets the required criteria described above.

  3. Once a draft is completed you must request the revision of the document through a Merge Request so that we can evaluate the content.

If the document is accepted and published the author transfers the copyrights of said document to Fluid Attacks; If necessary, changes will be made without the author’s consent.

Service status - Terms of Use