owasp-amass/amass · error
AddCredentials: The accountName argument is invalid
Error message
AddCredentials: The accountName argument is invalid
What it means
DataSource.AddCredentials adds a *Credentials entry under an accountName key, but rejects the call when accountName is the empty string or the receiver ds is nil. The error indicates a programming mistake by the caller rather than a config file problem: credentials were passed without a usable account identifier.
Source
Thrown at config/datasrcs.go:60
key := strings.ToLower(strings.TrimSpace(source))
if key == "" || c.DataSrcConfigs == nil {
return nil
}
var dsc *DataSource
for _, src := range c.DataSrcConfigs.Datasources {
if strings.ToLower(src.Name) == key {
dsc = src
break
}
}
return dsc
}
// AddCredentials adds the Credentials provided to the configuration.
func (ds *DataSource) AddCredentials(accountName string, cred *Credentials) error {
if accountName == "" || ds == nil {
return fmt.Errorf("AddCredentials: The accountName argument is invalid")
}
if ds.Creds == nil {
ds.Creds = make(map[string]*Credentials)
}
ds.Creds[accountName] = cred
return nil
}
// GetCredentials returns the first set of Credentials associated with the given DataSource name.
func (dsc *DataSourceConfig) GetCredentials(dsName string) *Credentials {
if dsc == nil || dsc.Datasources == nil {
return nil
}
for _, src := range dsc.Datasources {
if src.Name == dsName && src.Creds != nil {View on GitHub (pinned to 79299dce87)
Solutions
- Pass a non-empty accountName: ds.AddCredentials("account1", cred).
- Ensure the *DataSource receiver is non-nil before calling AddCredentials (check the lookup/constructor result).
- If the name comes from user input or env, validate it is non-empty before the call.
- Log or return which data source failed so the empty name's origin is traceable.
Example fix
// before
ds.AddCredentials(account, cred) // account may be ""
// after
if account == "" {
return fmt.Errorf("account name required for datasource %s", dsName)
}
ds.AddCredentials(account, cred) Defensive patterns
Strategy: type-guard
Validate before calling
if ds == nil {
return fmt.Errorf("datasource not initialized")
}
if accountName == "" {
return fmt.Errorf("accountName must be non-empty")
} Type guard
func addable(ds *config.DataSource, accountName string) bool {
return ds != nil && accountName != ""
} Try / catch
if err := ds.AddCredentials(name, cred); err != nil {
if strings.Contains(err.Error(), "accountName argument is invalid") {
// log which datasource/credential pair failed
}
return err
} Prevention
- Always check data-source lookups/constructors for nil before use
- Validate account names at their source (input, env, config)
- Wrap AddCredentials in a helper that enforces non-empty names
When it happens
Trigger: Calling ds.AddCredentials("", cred) with an empty account name, or calling the method on a nil *DataSource obtained from a failed lookup (e.g. GetDataSource returning nil).
Common situations: Programmatic config construction where the account name comes from a variable that is unset/empty; forgetting to check that a data source lookup succeeded before adding credentials; refactors that dropped the name assignment.
Understand the failure class
Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.
Related errors
- AddCredentials: The Credentials argument is invalid
- brute forcing cannot be performed without DNS resolution
- active enumeration cannot be performed without DNS resolutio
- resolvers section is not a list
- no valid resolvers were found
AI-assisted analysis of owasp-amass/amass@79299dce87 (2026-09-06).
Data as JSON: /api/errors/fd36089d5e669b03.
Report an issue: GitHub.