Proposed changes

As shown in the image above, when entering a value in a field like a password, appium leaks the value at the debug and info level. Since the above can also happen in a cloud provider like BrowserStack, leaking it even at the debug log level can compromise an actual production user account.

Since this approach would be the simplest and quickest, I would like to explicitly exclude it before going into full implementation of the dynamic regular expression to filter the logs as specified here

By using markSensitive to leverage the header X-Appium-Is-Sensitive from the clever solution of PR #21123. We can now mask the password value and safely enter the passwords in input fields without worrying about leaks in logs (when no plugins are used 😉 ).

Pros:

• Built-in with Appium
• Easy to use by users: need to pass a simple header
• No need to keep sensitive data (or part of it as a RegExp) in memory, which is a security OWASP point. See here

Cons:

• A new line of code could expose the sensitive data without using the new markSensitive function.
• A third-party plugin could not check this header and leak the password values in the logs.

Remaining tasks:

• Add unit tests
• Test in my enterprise app
• Reveiw wdio PR to use the new header
• Finish the below template
• Set PR to ready

These are draft changes, and if the idea is accepted, I will implement all required unit tests

Types of changes

What types of changes does your code introduce to Appium?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the Contributing Guide
• I have signed the CLA
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

Further comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...