Usar uma classe de modelo que possui propriedades obrigatórias não anuláveis (marcadas com o atributo [Required]) pode provocar problemas quando um invasor comunica uma solicitação que contém menos dados do que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo.

Se um modelo tiver um parâmetro obrigatório não anulável e um invasor não comunicar esse parâmetro em uma solicitação -- ou seja, se o invasor usar um ataque under-posting --, a propriedade terá o valor padrão (geralmente zero), que atenderá ao atributo de validação [Required]. Isso pode provocar o comportamento inesperado do aplicativo.

O código a seguir define uma classe de modelo possível que possui uma enumeração obrigatória não anulável:

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

Se uma classe de modelo tiver a propriedade obrigatória e for do tipo de um membro opcional de uma classe de modelo pai, ela poderá ser suscetível a ataques under-posting se um invasor comunicar uma solicitação contendo menos dados que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo, incluindo submodelos.

Se um submodelo for opcional -- ou seja, se o modelo pai tiver uma propriedade sem o atributo [Required] -- e se um invasor não comunicar esse submodelo, então a propriedade pai terá um valor null, e os campos obrigatórios do modelo filho não serão confirmados pela validação de modelo. Essa é uma das formas de ataque under-posting.

Considere as seguintes definições de classe de modelo:

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

Se um invasor não comunicar um valor para a propriedade ParentModel.Child, a propriedade ChildModel.RequiredProperty terá um [Required] não confirmado. Isso pode produzir resultados inesperados e indesejáveis.

De acordo com a política da Apple, o aplicativo deve sempre explicar aos usuários por que suas impressões digitais são necessárias. Não fazer isso pode confundir o usuário ou mesmo fazer com que o aplicativo seja rejeitado na AppStore.

Exemplo 1: O código a seguir usa a ID de toque para autenticar o usuário, mas não fornece um motivo localizado que explique porque a autenticação é necessária:

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

Mesmo que o Castor crie um bloqueio em um objeto, ele não impede que outros threads leiam ou gravem nele. Consultas somente leitura também são cerca de 7 vezes mais rápidas em comparação ao modo compartilhado padrão.

Exemplo 1: O exemplo a seguir especifica o modo de consulta como SHARED, o que permite acesso de leitura e gravação.

results = query.execute(Database.SHARED);

Por padrão, o Castor executa consultas no modo compartilhado. Como o modo compartilhado permite o acesso de leitura e gravação, não está claro para que tipo de operação a consulta se destina. Se o objeto for ser usado em um contexto somente leitura, o acesso compartilhado adicionará sobrecarga de desempenho desnecessária.

Exemplo 1: O exemplo a seguir não especifica um modo de consulta.

results = query.execute();    //missing query mode

Em algum momento na carreira do todos os desenvolvedores .NET, surge um problema que parece ser tão misterioso, impenetrável e impermeável a depurações que parece não haver nenhuma alternativa a não ser culpar o coletor de lixo. Especialmente quando o bug está relacionado ao tempo e ao estado, pode haver uma pitada de evidência empírica para apoiar essa teoria: inserir uma chamada em GC.Collect() às vezes parece fazer com que o problema desapareça.

Em quase todos os casos que temos visto, chamar GC.Collect() é a coisa errada a se fazer. Na verdade, chamar GC.Collect() pode causar problemas de desempenho isso for feito com demasiada frequência.

Em algum momento na carreira do todos os desenvolvedores Java, surge um problema que parece ser tão misterioso, impenetrável e impermeável a depurações que parece não haver nenhuma alternativa a não ser culpar o coletor de lixo. Especialmente quando o bug está relacionado ao tempo e ao estado, pode haver uma pitada de evidência empírica para apoiar essa teoria: inserir uma chamada em System.gc() às vezes parece fazer com que o problema desapareça.

Em quase todos os casos que temos visto, chamar System.gc() é a coisa errada a se fazer. Na verdade, chamar System.gc() pode causar problemas de desempenho isso for feito com demasiada frequência.