Mobile CyberSecurity: Quick Access sheet

This post is created to provide a concise collection of resources on specific web application security topics.

OWASP Mobile Top 10 2016 Proposed List

M1 – Improper Platform Usage This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of Touch-ID, the Key-chain, or some other security control that is part of the mobile operating system.
M2 – Insecure Data Storage This new category is a combination of M2 + M4 from Mobile top 10 2014. This covers insecure data storage and unintended data leakage.
M3 – Insecure Communications This covers poor handshaking, incorrect SSL versions, weak negotiation, clear-text communication of sensitive assets, etc…
M4 – Insecure Authentication This category captures notions of authenticating the end user or bad session management. This can include: (1) Failing to identify the user at all when that should be required. (2) Failure to maintain the user’s identity when it is required. (3) Weakness in session management.
M5 – Insufficient Cryptography The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way.
M6 – Insecure Authorization This is a category to capture any failures in authorization (e.g. authorization decision in the client side, forces browsing, etc…). It is distinct from authentication issue (e.g. device enrollment, user identification, etc…). If the app does not authenticate the users at all in a situation where it should (e.g. granting anonymous access to some resources or services when authenticated and authored access is required) then that should be authenticated failure not authorization failure.
M7 – Client Code Quality This was the “the security decision via the untrusted inputs”, one of OWASP lesser used category. This would be the catch-all for code-level implementation problems in the mobile clients.
M8 – Code Tampering This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification.
M9 – Reverse Engineering This category includes analysis of the final code binary to determine its source code, libraries, algorithms, and other assets.
M10 – Extraneous Functionality Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment.

Top Mobile Scanning tools

Portswigger – Burp





Additional resources


ENISA – European Union Agency for Network and Information Security – IoT and smart infrastructures.



HTTP Status Code



Agile Software Development: the Artifacts

Scrum is a framework for developing complex products. It is an interactive, incremental approach to optimize predictability and control risk.

The Scrum Artifacts

Scrum artifacts are tangible by-products produced during the product development. These artifacts consist of the requirements for the overall project, and each individual phase of the project itself.


The product backlog is an evolving, dynamic and ranked list of requirements that might be needed to made the product. The product owner is responsible for the product backlog, including its content, and ranking.

The product backlog lists all features, functions, requirements, enhancement and fixes that constitute the changes to be made to the product in future releases. In agile terminology, the product backlog item are called user stories.

The user stories are the smallest units of work, and its goal is to delivered customer’s value at the end of the iteration. A good user story should be:

Letter Meaning Description
I Independent The user story should be self-contained, so that there is not a dependency with another story
N Negotiable User stories, up until the start of the iteration, can be rewritten and re-ranked.
V Valuable A user story must deliver value to the end user
E Estimable The story is precise and concise so that the development team can estimate it.
S Small The user story development should conclude at the end of the iteration.
T Testable The user story and/or its related description must provide the necessary information to make test development possible.


Epics are feature-level work that encompasses many user stories. Epics are:

  • A Group of related user stories.
  • They use the same wording and format as the user story:
    • Short description;
    • Acceptance criteria;
    • Estimate.
  •  Should not be worked on directly.
  • Can be considered a project.
  • its works can spam more than one release and encompasses more than one product.

The Epic is typically used to monitor and track the development work toward the close proximity of the product release/launch.


Themes are feature-level work that encompasses many epics. They are:

  • A Group of related Epics.
  • They use the same wording and format as the Epics:
    • Short description;
    • Acceptance criteria;
    • Estimate.
  •  It’s a tracking tool to monitor the overall direction.
  • It’s considered as a Portfolio.
  • It is also called an Adventure.

The Theme is typically used to discuss with the CEO and board members for tracking the overall strategy direction.


Design your first Usability Test

Participants and Sample Size

“5 users will uncover approximately 80% of all usability problems”

– Nielsen Norman Group

Sample Size & Reliability

The more people find the same problem, the more reliable the data set becomes.

Multiple Rounds of Testing

Multiple round of testing on 5 different users covers more issues than a single round of testing with the same number of users.

User 1 User 6 User 11 User 1 User 9
User 2 User 7 User 12 User 2 User 10
User 3 User 8 User 13 > User 3 User 11
User 4 User 9 User 14 User 4 User 12
User 5 User 10 User 15 User 5 User 13
User 6 User 14
User 7 User 15




User 8 User 16
of issues of remaining issues of remaining issues


of issues


Selecting the right people

You need to select the participants based on the following criteria:

  1. User Profiles
  2. Personas
  3. General Data about your User base

and factors:

  1. The users understanding of the product.
  2. The Familiarity with the Product or Type of Product.
  3. Amount of overall Experience

And Recruiting criteria:

  1. Sample Size – how many people can you effort to bring in to test.
  2. Characteristics of the user – about the criteria being defined.
  3. Number of Participants for Each Personas or Characteristics.





Quick simple functions Provide the partecipant context and direction
Easily completed without any background information given Set the stage, tell the story
Find the Search button Increase overall understanding
Where would one go to out information about specific terms Help the user apply the situation to themselves
Give them an action to perform


Usability Scenarios

  1. Uses the vocabulary that the participant uses.
  2. The actions are clear and precise.
  3. Provides all the details needed to complete the goal.
  4. Does not provide steps and definitely does not give away the answer.
  5. You would like to buy a car, you would like to lease it for 36 months term with 1500 down. How would you do this?

Rating your results

a. Easy or under a minute to find/answer – – – —2 points

b. Difficult, takes 1-2 minutes to find/answer —-1 point

c. Fail, takes over 2 minutes to find/answer ——0 point


Types of Usability Tests

Formative Testing

Formative testing is usually conducted during website development and is typically used to test a specific feature like the design of a button or the findability of a piece of specific content, etc…

For example: is the user able to find the email form and be able to subscribe to the newsletter? Or is the user able to find a piece of content given the labeling of the button?


Summative Testing

Summative testing is conducted at the end of the development, the “Summation” of the development process. Summative testing is used to determine whether a website has successfully accomplished all of its goals.


Qualitative vs. Quantitative Testing

Related to, measuring, or measured by the quantity/quality of something rather than its quality/quantity.